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[57] ABSTRACT 

In a local communication system comprising a number of 
devices (14.16) interconnected by a first data bus (20) 
supporting a first set of communication protocols, and at 
least one further device (10) connected to a second bus (12) 
not supporting those protocols, a gateway device (18) is 
provided linking the first and second data buses enabling 
communications therebetween. The first set of protocols 
specifies a maximum time for response by a first device to 
a request sent by a second device. When a request is sent 
from a device (14) on the first bus to the further device (10). 
the gateway (18) times the request and. if no response is 
received from the further device within the specified maxi- 
mum response time, the gateway (18) generates and sends a 
temporary response to the requesting device (14). The 
system may comprise two or more clusters of devices, each 
being linked to the further bus (12) by respective gateway 
devices (18.22). 

19 Claims, 6 Drawing Sheets 
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INTERCONNECTION OF LOCAL 
COMMUNICATION BUS SYSTEM 

This is a continuation of application Ser. No, 08/394,977. 
filed Feb. 27. 1995 now abandoned. 

The present invention relates to a local communication 
system comprising a plurality of stations interconnected for 
the communication of messages via a first data bus and in 
accordance with a first set of communication protocols, at 
least one further station not supporting the said protocols, 
and a gateway device linking the first data bus and further 
station and operable to enable communications therebe- 
tween. The invention further relates to apparatus for use with 
such a system. 

One known set of communications protocols is the 
Domestic Digital Bus (D2B) Standard, standardised by the 
International Electrotechnical Commission. Geneva. 
Switzerland, and issued under reference IEC 1030. D2B 
consists of a package of communication protocol specifica- 
tions and system requirements, defining the way in which 
consumer electronics products can access and control each 
others functions via the Domestic Digital Bus. D2B is a 
general purpose control bus which also supports the transfer 
of limited amounts of digital data. Currently the main 
application area is Audio/Video (AV) equipment. 

With all such domestic equipment interconnection 
schemes, there is a problem of connection to apparatus not 
supporting the cornmunications protocols of the scheme. As 
an example, a user may have a music system comprising 
interconnected units such as a compact disc (CD) player, 
amplifier, tuner and cassette player which communicate with 
each other using a first set of communications protocols, 
together with an audio visual system comprising for 
example a television, video recorder and satellite receiver 
which communicate using a second set of protocols. In the 
absence of a certain degree of compatibility with existing 
systems, a user be faced with having to replace many items 
at one time. One way to reduce this problem is to provide a 
gateway device which supports two or more sets of com- 
munications protocols and can "translate* messages 
between them. 

A D2B can be used as a subsystem within a home 
electronic bus (HEB) system, and the EEC Standard 1030 
specifies in Section 11 thereof certain minimum require- 
ments for a gateway device linking the D2B to the HEB. A 
problem which occurs with gateway devices, relates to the 
timing of messages and in particular the time within which 
any device requesting information from another may expect 
to receive a response. When a first device receives a request 
from another device connected to its own local bus system, 
it should make an answer available as quickly as possible: a 
maximum response time may be specified such that no 
device becomes "jammed" whilst waiting for a response 
from a device which for some reason is unable to answer. 
However, in the present situation of gateway 
communication, such as from one D2B cluster to another via 
an intermediate bus system not supporting D2B protocols, 
an inevitable and unpredictable delay may occur due to the 
delay of transmission via the intermediate bus. 

In accordance with the present invention there is pro- 
vided a local communications system of the type set forth in 
the opening paragraph wherein the first set of communica- 
tions protocols specifies a maximum time for reply by a first 
station to a message sent by a second station, and wherein 
when a message requiring a response is passed between a 
station of the first bus system and the said further station via 
the gateway device, the gateway device is configured to 


2 

generate and send a temporary response to the message 
originating station, within a predetermined period less than 
the specified maximum response time, pending arrival of a 
response from the station receiving the message, and sub- 
5 sequently passes the said response on its arrival. Preferably, 
the gateway device includes memory means within which a 
record of a message passed is stored 

Following the sending of a temporary response to a first 
requesting station, the gateway device is preferably operable 
10 to pass messages from other requesting devices, with the 
memory means maintaining a record of the first message. 

The gateway device may support requests from stations 
connected to the first data bus for information regarding the 
identity of further gateway devices beyond the gateway and 
is be operable to pass messages to further stations via such 
further gateway devices, including messages verifying or 
detecting the presence of stations beyond further gateways. 

Additionally, the gateway device may be operable to 
emulate, to each station connected to the first data bus and 
20 in accordance with the first set of communications protocols, 
the behaviour of the or each further station linked to the first 
bus through the gateway device. 

Where the system comprises two or more clusters of 
stations, each cluster comprising a plurality of stations 
25 interconnected by a respective data bus and communicating 
within the cluster in accordance with respective sets of 
communications protocols, the clusters may be linked to 
each other by a further communications bus supporting a 
further set of communications protocols, with each being 
30 linked to the further bus by a respective gateway device. 
By providing a temporary response, the gateway device 
handles any inconsistencies of timing with the temporary 
response meeting the requirements for a response to be 
received within a maximum period. 
35 Further features and advantages of the present invention 
will be apparent from reading of the claims and the follow- 
ing description of preferred embodiments of the present 
invention, now described by way of example only and with 
reference to the accompanying drawings in which: 
40 FIG. 1 schematically represents a domestic audio/visual 
application using a number of interconnection buses; 

FIGS. 2 and 3 are block schematic representations of a 
gateway device linking two data buses: 

FIG. 4 illustrates linking of two local data network 
45 clusters; 

FIG. 5 illustrates gateway numbering in a multiple clus- 
ter network system; 

FIG. 6 schematically illustrates the determination by a 
first gateway device of numbers of other gateway devices; 
50 FIG. 7 represents the determination by a device con- 
nected to a first gateway of the configuration of a device 
connected to a second gateway; 

FIG. 8 is a timing diagram illustrating gateway timing 
management; 

55 FIGS. 9 and 10 are timing diagrams for signal path 
building in source and destination clusters; 

FIGS. 11 and 12 represent emulation by a gateway; and 
FIGS. 13 to 15 represent methods for RF and baseband 
signal handling in cluster interconnection. 
60 The following description will cover the enabling by a 
gateway device embodying the present invention of access 
by devices on a first bus system (referred to hereinafter as an 
X-bus) to the functions available within a D2B system and 
vice versa, via the gateway device. 
65 An example of such an application, as shown in FIG. 1. 
comprises a telephone 10. attached to an X-bus 12 and using 
the on-screen display (OSD) function of a television 14 
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wilhin a D2B cluster (of which television 14. a VCR 16 and 
gateway 18 connected via D2B 20 are shown). The tele- 
phone 10 could use the OSD function to display a message, 
perhaps to announce that there is a call and give details of 
the caller. Alternatively, the telephone 10 may be used to 
program the VCR 16 of the D2B cluster from a remote 
location. 

As also shown in FIG. 1, more than one D2B cluster may 
be connected via the X-bus 12 with each cluster being 
connected thereto via a respective gateway 18.22. 
Accordingly, the gateways 18.22 enable application mes- 
sages to be sent not only between devices in a D2B cluster 
and devices on the X-bus. but also between devices in 
separate D2B clusters. 

The gateway 18 provides a logical interface between the 
D2B and X-Bus which manages the transfer of messages 
from D2B to X-Bus transparently. 

As shown in FIG. 2. the gateway 18 is in charge of the 
protocol interface between D2B and X-Bus. and its func- 
tionalities are concerned with the communication between 
D2B and X-Bus. with a message from a D2B device 24 
translated into an X-Bus message by the X-Bus protocol of 
the gateway, and transferred to an X-Bus device 26. Where 
the X-Bus device is a further D2B cluster (as in FIG. 1). the 
X-Bus message is translated into D2B protocol by the 
gateway 22 connecting the further cluster to the X-Bus 12. 

FIG. 3 shows the D2B side of the gateway device 18, 
with a gateway subdevice 30 providing an interface to the 
X-Bus protocols 28 and in charge of the basic role of 
executing transparent message communication with a device 
outside of the cluster. The gateway subdevice 30 is neces- 
sary to permit basic applications such as controlling simple 
devices via the D2B gateway. For more complex 
applications, the device containing the gateway 30 may 
include other subdevices such as a switchbox subdevice 32 
to make signal connections to and from a D2B cluster for 
audio/video signal distribution. For other applications such 
as central control from the gateway, an AVC subdevice 34 
and a user I/O subdevice 36 may be required within the 
gateway device. 

If the gateway is connected to more than one network, for 
example X-Bus A and X-Bus B. then the gateway subdevice 
30 provides separate protocol interfaces for each network. 

Referring again to FIG. 1. when a device or subdevice in 
one D2B cluster (in this case the television 38) wishes to 
send an application message to a device or subdevice in 
another D2B cluster (a playback command to VCR 16). the 
application on the source device assembles the gateway 
routing information together with commands and requests 
into an application message which is placed in a D2B 
message. The devices' communication facilities send the 
D2B message to the gateway 22 within its own cluster. The 
gateway routing information in the D2B message contains a 
gateway number which identifies the gateway 18 of a D2B 
cluster to which the message should be sent. 

The first cluster gateway 22 uses this gateway number to 
pass the contents of the message, via the connecting X-Bus 
12 to the gateway 18 of the destination cluster. When the 
message reaches the gateway 18 of the receiving cluster, the 
gateway 18 replaces its own number in the routing infor- 
mation with that of the gateway 22 of the originating cluster 
such that the device or subdevice receiving the message can 
identify its originating cluster. The receiving gateway 18 
then uses the altered application message to generate a new 
message conforming to D2B protocols for passage via D2B 
20 to its destination device or subdevice. 

When a device or subdevice in one D2B cluster wishes 
to send an application message to a device on the X-Bus 
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(which device supports messages from the D2B cluster 
device), such as television 14 sending control commands to 
security camera 40. television 14 assembles the gateway 
routing information together with commands and requests 

5 into an application message, which is placed in a D2B 
message. In this instance, the gateway routing information 
contains the gateway number of the gateway 18 within the 
originating cluster The televisions network communication 
facilities send the D2B message to the identified cluster 

10 gateway 18 for transmission over the X-Bus to the camera 
40. 

When a device on the X-Bus wishes to send a message 
to a device in a D2B cluster, the message is sent via X-Bus 
to a gateway 18 for that cluster where a D2B message 

is identifying the receiving gateway is assembled and then 
passed over the D2B to the destination device e.g. VCR 16. 

On each bus. each device has an address. Gateway 
devices therefore have two addresses, one for each bus to 
which they are attached. In the example shown in FIG. 4. 

20 two gateway devices 42.44 for respective D2B clusters are 
connected to X-Bus 12. It will be understood that in this 
example, any relationship between the gateway number. 
D2B address and X-Bus address is strictly coincidental. 
Suitably a limit of 8 gateway devices connected to a 

25 single D2B bus system is imposed, with the D2B addresses 
for the gateways as follows: 


TABLE 1 


30 


bit 11 


bit 0 

bit 11 


bitO 

0000 

10110 

OOOCOBO'H) 

0000 

11110 

OOOCQFO'H) 

0000 

10110 

OOl(X)BrH) 

0000 

11110 

OOlCOFl'H) 

0000 

10111 

OOOCOBS'H) 

0000 

11111 

0O0('0F8'H) 

0000 

10111 

001(*OB9'H) 

0000 

11111 

001('OF9'H) 


35 


The address of the D2B gateway device is specified in the 
Communication Telephony (CT) service type area (service 
type specified as *0000'H). 

A further limit, of only one gateway subdevice within a 

40 device on D2B. is imposed. The gateway subdevice address 
is allocated in the CT service area and specified as 'OBO'H — 
as the first entry in Table 1 above. 

For a D2B device, only one address is allowed. The 
device address of the gateway is determined by the main 

45 functionality of the device, which is implementor defined. If 
the gateway is a stand-alone gateway (that is to say not as a 
subdevice of a D2B AV device), one of the eight gateway 
addresses is allocated to it. When a gateway is implemented 
as one of the subdevices in an AV device, the device may be 

50 defined with an AV device address. If the gateway subdevice 
is implemented in for example a television set with other 
subdevices such as a monitor subdevice. a tuner subdevice. 
a switchbox subdevice and others, the device containing the 
gateway subdevice will be identified by the video monitor 

55 subdevice. which is the main function of that device. If a 
gateway subdevice is implemented in an X-Bus device such 
as a room controller or telephone, for controlling D2B 
devices with D2B protocols, an AVC subdevice is necessary, 
even though the X-Bus device has no particular AV function. 

60 In this case, an AVC device address is allocated to the X-Bus 
device. 

Each gateway subdevice is allocated a 4-bit encoded 
gateway number. In a system which consists of a D2B 
cluster and an X-Bus connected via a gateway, a maximum 
65 of 16 gateways are permitted. Every gateway either knows 
or can determine all the gateways which are connected to 
either of the busses it connects. The gateway number is used 
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by a gateway subdcvicc to logically identify the known For an application using the devices in different D2B 

gateways. It is used when a message is going to be sent from clusters, a device in one cluster may need to know whether 

one network to another via a gateway. Each gateway needs the requested functionality is available in other clusters and 

to number its known gateways and store them. to which device in the other cluster it should send a message. 

In FIG. 5. a cluster 46 (D2B f ) is going to be connected to 5 j 0 obtain this information, the interested device may ask 

X-Bus 12 via gateway 48 (GWnew). After connection to with a rcquC st message from one cluster to another via a 

X-Bus, gateway GWnew needs to know its possible gate- gateway. In order to communicate via a gateway, the device 

waysontoth X-Bus and^ needs t0 ^ow the gateway numbers, the addresses of 

GWa to GWd on X-Bus and GW A , and OW r 00 D2B\ devices in mc Tcmo * duf k and mc addrcsses of me 

For gateways on X-Bus. the X-Bus side of the gateway subdevices m ^ remote devicC( to be uscd ^ ^ ^ 

GWnew collects addresses of the gateways on X-Bus and 6 

informs the (D2B side) gateway subdevice of them. The commann. ^ 

X-Bus side of the gateway needs to have a table of the . For a device which is going to communicate with a device 

allocated gateway numbers and the X-Bus address of each 10 a remote cluster lt ls necessary to know which other D2B 

gateway wherein GWnew and GWa to GWd (all X-Bus cIusters m available. Each gateway on X-Bus needs to get 
addresses) are respectively numbered 1 to 5. For gateways 15 and store information before gateway communication is 

on D2B\ the gateway subdevice in GWnew investigates required. How to gather this information is implementor 

whether there is/are any other gateway(s) on D2B' and, if defined and based on the X-Bus protocols, and the interested 

there are any. it stores the address of the/each such gateway. device can ask the gateway to send this information with an 

In the present example. D2B* addresses GW A and GW^. are "available clusters?** request The gateway which receives 

stored in the table as numbers 6 and 7 respectively. 20 the request returns the gateway numbers of the available 

When a message is going to be transferred from a device gateways belonging to the X-Bus. as shown for gateway 

in D2B' to X-Bus via GWnew, the gateway translates the GW1 in FIG. 6. 

gateway number to the corresponding X-Bus address and in D2B a device can discover the configuration of other 

transfers the received message to it When a message is sent devices conforming to the protocol and connected to the bus. 

from X-Bus and is going to be transferred to D2B\ the 25 configuration (i.e. the number of subdevices and the 

gateway subdevice in GWnew translates the gateway num- address of ^ ^ ^ determined by an interested device 

ber to the corresponding D2B address and transfers the sending a <mjmber of subdfivice?> request< similarly, a 

received message to the device. device in a ^ D2 B cluster can discover the configuration 

In the same way, GWa may have its own possible of a dev ice in a second D2B cluster by sending the request 

gateway numbers independently from any other gateway ^ v j a x-Bus 

numbers such that, for GWa the table gives GWa to GWd nQ ^ 7 mustrates ^ obtaining of remote cluster and 

™, G X-Bus addresses) as 1 to 5 respectively and device configuration info in an example system Supposing 

G^to GW C (all D2B addresses) as 6 to 8 respectively. mat the AVC subdevicc 0 f VCR 52 in the D2B cluster 1 

The basic functions of the gateway subdevices are to waDts t0 ^ ^ devicc which can me video signa) 

execute the routing command and set up the routing of the 35 of me ^ck subdevice 54 in the D2B cluster 2. Firstly, the 

messages to the network beyond the gateway, and to receive AVC 50 ^ t0 find ^ xv 56 in the remote cluster. The 

a TSSS ** D u tWOrk aDd d AV C 50 sends the request to the remote cluster with a 

it the D2B device with a routing command which specifies routiflg followcd by mc monitQr ^tot as a 

the routing informaUon. m destination address. The TV 56 with a monitor device 

The details of the routing command will be described in ^ address m the remote duster answcn for this t b 

greater detail hereinafter. In order to execute these functions, scnding me numbcr of Us subdcviccs and ^ addrcss of cac £ 

in addition the gateway must also have the following of ^ ^ ^ AVC subdcvice 

in the local cluster can 

(necessary for gateway communication): ^ ^ Decessary address information of which it should 

Ouster management to provide the device with the capa- communicate for its application (in this case the monitor 

bility to get necessary information for communication 45 subdevice 58). 

with a device outside of its cluster; For me communication from a device on X-Bus. such as 

Timing management to guarantee proper communication camera unit 60 (FIG. 7). to a device in the D2B cluster, the 

timing within a D2B cluster according to D2B com- X-Bus device needs to know to whom it should send a 

munication management protocols. message. Supposing that the camera unit 60 on the X-Bus 12 

In remote AV applications, it may be needed to distribute 50 wants to send a video signal to the D2B device which can 

signals via a gateway. In order to make it possible to transmit display the picture of the video signal on the display facility : 

an AV signal from one cluster to another cluster or between in effect the camera wishes to know whether there is a TV 

the D2B and the X-Bus, the D2B gateway may optionally in the D2B cluster. Firstly, the camera 60 sends a message 

nave: to request device configuration with a monitor device 

A signal distribution function executed by a gateway 55 address as a destination address. In this sequence, commu- 

subdevice acting as an AV source or destination and a nication between the camera 60 and the X-Bus side gateway 

switchbox subdevice to make signal connections in the subdevice of the gateway device 62 of the cluster is executed 

D2B clusters). with the X-Bus protocols. The X-Bus side gateway trans- 

In the following paragraphs, these functions of cluster lates a received X-Bus format message into the appropriate 

management, timing management and signal distribution 60 D2B message (the <number of subdevices?> request), and 

functions are described in greater detail. passes it to the D2B side gateway subdevice of gateway 62. 

Cluster Management The gateway subdevice sends the request to the monitor 

Within the D2B cluster each device is able to read subdevice 58 following a routing command and its operand, 

property memories of other devices. For example a VCR is If an answer is obtained properly from the D2B device, the 

able to send requests to other devices to find out which one 65 gateway subdevice passes it to the X-Bus side gateway 

can display a picture. In the same way. the configuration of subdevice which then transfers it to the camera unit 60 using 

a cluster can be gathered by the gateway. the X-Bus communications protocols. 
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In addition, if the camera unit 60 wants to send its video 
signal to the device which has a recording facility, it can 
investigate whether there is a device with such a facility in 
the D2B cluster in the same way by sending a message to 
request device configuration with the address of a deck 5 
device as a destination address. In this instance the address 
for the deck subdevice 64 of VCR 66 will be returned. 

If a device in the D2B cluster wants to know the con- 
figuration of a device on the X-Bus. it is obtained in the same 
way with requests being translated between protocols at the 10 
gateway. 

Timing Management: 

When a subdevice receives a request, it should make an 
answer available as quickly as possible. However, in the 
present situation of gateway communication, such as from 15 
one D2B cluster to another, an inevitable and unpredictable 
delay may occur due to the delay of transmission via the 
X-Bus. The timing management by the gateway subdevice is 
executed by providing a temporary answer to the device 
which has sent the request to a device within another cluster. 20 

Referring again to FIG. 7 and also to the timing diagram 
of FIG. 8. it is assumed that device 1 in cluster 1 wants to 
get property info from device 4 in cluster 2 using a request 
and answer. In this situation the procedure is as follows. 
Firstly, device 1 sends a request to gateway GW1 with a 25 
routing command. Until GW1 obtains the, final answer (for 
example the message "executing") from device 4 in cluster 
2. GW1 returns a temporary answer for the request from 
device 1 within a specified minimum response time. Note 
that, in order to prevent occupation of the gateway subdevice 30 
(slave) by a particular master during a request sequence, the 
device sending a request needs to unlock the gateway by 
issuing an <end> command after receiving a temporary 
answer from the gateway. Before the next request from 
device 1 is received, the gateway subdevice may receive a 35 
message to be transferred beyond the cluster from another 
D2B device (e.g. device 2). Even in such a case, the gateway 
subdevices must keep the ongoing request sequence by 
device 1. 

The second stage of the procedure is the transfer of the 40 
request from GW1 to GW2. This procedure must be 
executed by means of communications between the gate- 
ways according to X-Bus protocols and D2B routing pro- 
tocols. Thirdly, GW2 sends a request to device 4 which is 
repeated until a final answer is obtained. The fourth stage is 45 
the return by device 4 of the answer (which may be the final 
answer). The fifth stage is the transfer by GW2 of the 
obtained answer with the final value to GW1. and the storage 
by GW1 of the final answer: again, this is executed by means 
of communication between the devices according to X-Bus 50 
protocols. The final stage is the return of the answer with the 
final value from GW1 to device 1. 
Signal Distribution: 

As previously mentioned, the signal distribution function- 
ality is optional, although it will be recognised that it is 55 
required for an application using av signals via D2B and an 
X-Bus which can carry av signals. It will also be recognised 
that, for signal distribution functionality, both the signal 
connection in AV clusters and signal presentation to X-Bus 
are required. In the following paragraphs, it is assumed that 60 
the X-Bus has AV signal capability. 

Within a D2B cluster, the signal connection is made by the 
AVC subdevice at baseband from a 'source* to 4 destination', 
possibly via one or more switchboxes. If a signal has to be 
transferred via X-Bus. the local destination will be the 65 
gateway. Between different D2B clusters, the related com- 
mands and requests are transferred with the routing com- 
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mand: actual switching on the X-Bus has to be done accord- 
ing to X-Bus protocols. 

The basic procedures for connection in both source and 
destination clusters will now be described with reference to 
FIGS. 9 and 10 which are timing diagrams for signal path 
building in the source cluster (FIG. 9) and in the source 
cluster and destination cluster (FIG. 10). 

In the connection procedure for a source cluster, the 
subdevice address of the gateway subdevice is specified as 
a <destination> in the <connect source destination 
command, a <connect switch box> command, a <connect 
switchbox completed^ command, and a <connect source 
destination completed> command. After completion of the 
signal path both in the source cluster and in the destination 
cluster, the gateway with X-Bus may start switching and 
building signal path connection on the X-Bus. 

If a connection is going to be made to a remote cluster 
(destination cluster), the connection in the destination clus- 
ter is made from the gateway subdevice to the destination 
subdevice (e.g. a monitor subdevice) in the destination 
cluster by the AVC subdevice as that which has made a 
source signal connection. In mis case the remote gateway 
subdevice acts as a source subdevice in the destination 
cluster. The connection in the destination cluster can be 
made independently from the connection in the source 
cluster. The AVC subdevice in the source cluster sends a 
<connect source destination> command to the gateway 
subdevice in the destination cluster to establish a connection 
in the destination cluster. The commands <connect source 
destination> and <connect source destination completed> 
are transparently transferred from one cluster to another with 
the routing command. After the connections both in the 
source cluster and in the destination cluster are established, 
the signal can be transferred from the source subdevice in 
the local cluster to the destination subdevice in the remote 
cluster. 

The gateway device is operable to emulate, to each station 
connected to the first data bus and in accordance with its 
local set of communications protocols, the behaviour of the 
or each further station linked to the first bus through the 
gateway device. FIG. 11 shows a pair of such an "emulating 
gateways** with the gateway in Room 1 emulating the 
television in Room 2. and the gateway in Room 2 emulating 
the VCR in Room 1. In an extension to this system, where 
a number of devices are connected together in a cluster 
supporting a first protocol (in this instance Audio control) 
one of the devices, may act as an emulating gateway imitat- 
ing the AV system as a whole to the television on the D2B 
bus. as shown in FIG. 12. 

Signal presentation depends on the X-Bus protocols and 
also depends on the applied signal allocation mechanism for 
the X-Bus, e.g. static-allocation, dynamic-allocation an so 
on. This means that the signal presentation functionality is 
necessary for a feature requiring signal distribution but the 
actual signal switching must be carried out using the X-Bus 
protocols. The following description refers only to D2B 
protocols. 

In the signal distribution of the destination cluster, the 
actual procedure including signal connections depends on 
the type of signal distribution system, and/or whether the 
destination gateway subdevice has capability to convert the 
signals from the X-Bus into the baseband signals which can 
be managed by the D2B protocols, and they are implemented 
defined. 

Three types of signal distribution systems will now be 
discussed with reference to FIGS. 13 to IS in which RF 
signal connections are shown as broad dark lines and 
baseband paths as broad lighter-coloured lines. 
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The first type comprises two clusters each supporting the linked by a data bus supporting a further set of communi- 
sarae set of communications protocols and linked by a data cations protocols. A signal path is established between a 
bus supporting a further set of communicatioDS protocols. A station of the first cluster and a station of the second cluster 
signal path is established between a station of the first cluster as radio frequency signal paths between each station and its 

and a station of the second cluster as baseband signal paths 5 local gateway and as a further signal path selected by one of 

between each station and its local gateway and as a further gateways from those available within the communica- 

signal path between the gateways and selected by one of the tions structure supported by the Unking data bus. This third 

gateways from those available within the communications W» of system is the simple signal distribution system (as 

structure supported by the Unking data bus. In this first type represented by FIG. 15). and the gateway does not have a 

of distribution system, signal connections in the local cluster 10 conversion capability. As the signal distribution 

(source cluster) and the remote duster (destination cluster) within a D2B clustcr is basc<J on interconnections of base- 

must be made by the AVC subdevice which is executing an Dand S1 8 nals , in this type of system, signal connections need 

application. The connection procedure both in the source * bv «"***r wav < c * manually) and D2B connec- 

and destination clusters must be done based on the existing ^on procedures are not necessary. The gateway subdevices 

D2B connection and protection protocols. 15 act onl y for transferring commands between clusters. 

For the signal interchange between an X-Bus and a D2B To avoid errors - the AVC subdevice which is responsible 

cluster or vice versa, the signal must be presented by the for ^ application using AV transfer via X-Bus must run the 

gateway subdevice. For the signal presentation in the connection procedure in an appropriate manner according to 

example shown in FIG. 13. the gateway subdevice 70 in the mc selected one of the above-mentioned three types of 

source cluster A plays the role of modulator from baseband 20 **** distributing system. Accordingly, the following rules 

to (one of) the frequencies which is applied on the X-Bus « observed by an AVC subdevice making connections 

signal line. If more than one frequency (or channel) is ^yond its cluster * n<i gateway subdevice in the desti- 

available, some procedure for selecting one of them may be nation clustcr * Fas ^ tf *« gateway subdevice which does 

necessary before signal transmission to the X-Bus 72. On the not havc the demodulating function receives the connection 

other hand, the gateway subdevice 74 in the destination 25 command from the AVC subdevice in the source cluster, the 

cluster acts as a demodulator from X-Bus format (RF) to gateway subdevice should not attempt to make connection in 

baseband. An AV signal from the monitor subdevice of TV its cluster - Secondly, if the AVC subdevice in the source 

76 in cluster A is switched to a switchbox 78 in the gateway cluster does not receive a <connect source destination com- 

70 and then modulated onto a coaxial cable or an optical P leted> command from the destination cluster, this means 

fibre. In the remote cluster B. the modulated signal (RF) is 30 mat me gateway subdevice in the destination cluster does 

put into the gateway 74 and demodulated to the baseband not have a demodulating function and the signal connections 

signal, and led to a monitor subdevice (the destination in ^ destination cluster must be effected by some other 

subdevice) in TV 80. means, e.g. manually. 

The second type of the system comprises two clusters From readin g disclosure, other variations will 

each supporting the same set of communications protocols 35 apparent to persons skilled in the art. Such variations may 

and linked by a data bus supporting a further set of com- involve ^er features which are already known in the 

munications protocols. A signal path is established between design, manufacture and use of local communication 

a station of the first cluster and a station of the second cluster systems, home entertainment systems and component parts 

as a baseband signal path from a first one of the stations to thereof and which may be used instead of or in addition to 

its local gateway, as a further signal path between the 40 Matures already described herein. Although claims have 

gateways and selected by one of the gateways from those bccn formulated in this application to particular combina- 

available within the communications structure supported by ^ons of features, it should be understood that the scope of 

the linking data bus. and as a Radio Frequency signal path me ^closure of the present application also includes any 

from the other of the stations to its other gateway. This novel feature or any novel combination of features disclosed 

second type applies an aerial type input in the destination 45 herein either implicitly or explicitly or any generalisation 

cluster, in which system the AV signals are directly led fro hereof. whcther or ** At relatcs t0 sarac invention as 

X-Bus to destination. The signal connections in the source presently claimed in any claim and whether or not it miti- 

cluster are made by the executing AVC subdevice as shown g ates ^ 01 & of mc samc technical problems as does the 

in FIG. 9. and the signal connections in the destination present invention. The applicants hereby give notice that 

cluster are made by alternative means, e.g. manually, such 30 new claims may be formulated to such features and/or 

that D2B connection procedures are not necessary. The combinations of such features during the prosecution of the 

gateway subdevice in the destination cluster does not need present application or of any further application derived 

a signal conversion (demodulation) capability, which is dune therefrom, 

by the tuner subdevice in the destination device. e.g. a TV. ^ c claim: 

In the example shown in FIG. 14, depending on the 55 1 - A local communication system comprising: 

frequency (or channel) used for modulation, the destination a plurality of stations interconnected for communicating 

must be tuned to the appropriate frequency before transmis- messages via a first data bus and in accordance with a 

sion which may be accomplished by the AVC in the local firs* se t of communication protocols; 

cluster sending a <frequency> or <channel> command to the at least one further station not supporting said protocols; 

tuner subdevice in the remote cluster. If a dynamically- 60 and 

allocated frequency is used for the signal on the X-Bus. the a gateway device linking the first data bus and the further 

gateway subdevice needs to know the possible frequency on station and operable to enable communications ther- 

the X-Bus for modulation of the AV signal. In such case, the ebetween; 

procedure for detecting a possible frequency on (he X-Bus wherein 

depends on the X-Bus protocols and is implemented defined. 65 the first set of communications protocols specifies a 

The third type of the system comprises two clusters each maximum time for reply by a first station to a 

supporting the same set of communications protocols and message sent by a second station, and 
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when a message requiring a response is originated by a 
station of the first bus system and passed to said 
further station via the gateway device, the gateway 
device is configured to (i) generate and send a 
temporary response to the originating station within 
a predetermined period less than the specified maxi- 
mum response time, pending arrival of a response 
from said further station, (ii) during said pendency 
provide for passage of a message to or from another 
station of the first bus system, and (iii) upon arrival 
of said response from said further station, pass said 
response to the originating station. 

2. A system as claimed in claim 1. wherein the gateway 
device includes memory means within which a record of at 
least one message passed thereby is stored 

3. A system as claimed in claim 2. wherein following the 
sending of said temporary response to the originating 
station, the gateway device is operable to pass messages 
from other requesting stations, with the memory means 
maintaining a record of the message requiring the response. 

4. A system as claimed in claim 3, in which the gateway 
device supports requests from stations connected to the first 
data bus for information regarding the identity of further 
gateway devices beyond the gateway and is operable to pass 
messages to further stations via such further gateway 
devices, including messages verifying or detecting the pres- 
ence of stations beyond further gateways. 

5. A system as claimed in claim 2. in which the gateway 
device supports requests from stations connected to the first 
data bus for information regarding the identity of further 
gateway devices beyond the gateway and is operable to pass 
messages to further stations via such further gateway 
devices, including messages verifying or detecting the pres- 
ence of stations beyond further gateways. 

6. A system as claimed in claim 1. in which the gateway 
device supports requests from stations connected to the first 
data bus for information regarding the identity of further 
gateway devices beyond the gateway and is operable to pass 
messages to further stations via such further gateway 
devices, including messages verifying or detecting the pres- 
ence of stations beyond further gateways. 

7. A system as claimed in claim 1. in which the gateway 
device is operable to emulate, to each station connected to 
the first data bus and in accordance with the first set of 
communications protocols, the behaviour of the or each 
further station linked to the first bus through the gateway 
device. 

8. A system as claimed in claim 1. wherein the plurality 
of stations are organized into at least first and second 
clusters, each cluster having a respective local gateway 
device and supporting the same set of communications 
protocols, the clusters being linked by a data bus supporting 
a further set of communications protocols, wherein a signal 
path is established between a station of the first cluster and 
a station of the second cluster as 

baseband signal paths between each station and its local 
gateway device and 

a further signal path between the gateway devices, the 
further signal path being selected by one of the gateway 
devices from those available within a communications 
structure supported by the Unking data bus. 

9. A system as claimed in claim 1. wherein the plurality 
of stations are organized into at least first and second 
clusters, each cluster having a local gateway device and 
supporting the same set of communications protocols, the 
clusters being linked by a data bus supporting a further set 
of communications protocols, wherein a signal path is 
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established between a first station of the first cluster and a 
second station of the second cluster as 
a baseband signal path from the first station to its local 
gateway device and 
5 a further signal path between the gateway devices and 
which further signal path is selected by one of the 
gateways from those available within the communica- 
tions structure supported by the linking data bus. and 
a Radio Frequency signal path from the second station to 
io its local gateway device. 

10. A system as claimed in claim 1. wherein the plurality 
of stations are organized into at least first and second 
clusters, each cluster having a local gateway device sup- 
porting the same set of communications protocols, the 

13 clusters being linked by a data bus supporting a further set 
of communications protocols, wherein a signal path is 
established between a station of the first cluster and a station 
of the second cluster as 
radio frequency signal paths between each station and its 
20 local gateway device and 

a further signal path selected by one of the gateway 
devices from those available within the communica- 
tions structure supported by the linking data bus. 

11. A local communication system comprising: 
25 a. two or more clusters of stations each cluster comprising 

a plurality of stations interconnected for communicat- 
ing messages via a respective data bus and in accor- 
dance with a respective set of communication 
protocols, at least one of the respective sets of com- 
30 munication protocols being a first set of communica- 
tions protocols; 
b. a further data bus for interconnecting the clusters, the 
further data bus not supporting the first set of commu- 
nication protocols; 
35 c. a plurality of respective gateway devices, one for each 
cluster, the gateway devices linking the clusters and the 
further data bus and being operable to enable commu- 
nications therebetween; 
wherein 

40 the first set of communications protocols specifies a 
maximum time for reply by a first station to a 
message sent by a second station; and 
each respective gateway device that is coupled to a 
cluster using the first set of communications proto- 
45 cols is configured (I) in response to a message 

originating station within that cluster, to generate and 
send a teiriporary response to the message originat- 
ing station within a predetermined period less than 
the specified maximum response time, pending 
50 arrival of a response from a message destination 

station outside that cluster, (ii) during said pendency 
provide for passage of a message to or from another 
station of that cluster, and (iii) upon arrival of said 
response from said message destination station, pass 
55 said response to the message originating station 

in which a nominated station (the "AV Center") 

has knowledge of signal paths in the cluster containing 

the message originating station; 
uses control messages to establish a signal path 
60 between the message originating station and the 

respective gateway device for the cluster containing 
the message originating station; and 
provides information to cause establishment of signal 
paths 

65 between the message destination station and the 

respective gateway device for the cluster contain- 
ing the message destination station; and 
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between the cluster containing the message originat- 
ing station and the cluster containing the message 
destination station via the further bus. 

12. A system as claimed in claim 11. in which the gateway 
of a first cluster is operable to emulate the system outside of 5 
its cluster as a station on its cluster data bus and in 
accordance with the communications protocols supported by 
that bus. 

13. A system as claimed in claim 11. wherein 

the signal paths between 10 
the first station and the respective gateway device of the 

first cluster; and 
the second station and the respective gateway device of 
the second cluster 
are both baseband signal paths and 15 
the "AV Centre" has knowledge of the baseband signal 
paths in both the first and second clusters and uses 
control messages for both the first and second clusters 
to establish the signal paths between the first and 
second stations and the respective gateways of the first 20 
and second clusters. 

14. A system as claimed in claim 11. wherein 
the signal paths between 

the first station and the respective gateway device of the ^ 

first cluster; and 
the second station and the respective gateway device of 
the second cluster 
are both baseband signal paths and the "AV Centre" 
has knowledge of the baseband signal paths in the first 30 
cluster and uses control messages to establish the signal 
path between the first station and the respective gate- 
way of the first cluster and 

provides information to allow a nominated station in 
the second cluster to establish the signal paths 35 
between the stations in the second duster and the 
respective gateway device for the second cluster. 

15. A system as claimed in claim 11, wherein 
the signal path between 

the first station and the respective gateway device of the 40 
first cluster is a baseband signal path; and 

the second station and the respective gateway device of 
the second cluster is a radio frequency channel; 
the nominated station (the **AV Centre") 

has knowledge of baseband signal paths in the first 45 
cluster and uses control messages to establish the 
signal path in the first cluster between the first station 
and the respective gateway device of the first cluster, 
and additionally 

the AV Centre uses control messages to control the 50 
appropriate use of a Radio Frequency channel in the 
second cluster. 

16. A system as claimed in claim 11. wherein 
the signal path between 

the first station and the respective gateway device of the 55 
first cluster is a baseband signal path; and 

the second station and the respective gateway device of 
the second cluster is a radio frequency channel; 
the nominated station (the "AV Centre") 
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has knowledge of baseband signal paths in the first 
cluster and uses control messages to establish the 
signal path in the first cluster between the first station 
and the respective gateway device of the first cluster, 
and additionally 

provides information to allow a nominated station in 
the second cluster to control the appropriate use of a 
Radio Frequency channel in the second cluster. 

17. A system as claimed in claim 11. wherein 
the signal paths between 

the first station and the respective gateway device of the 

first cluster; and 
the second station and the respective gateway device of 
the second cluster 
are both radio frequency channels; 
the nominated station uses control messages to control the 
appropriate use of a Radio Frequency channel in the 
first and second cluster. 

18. A system as claimed in claim 11. wherein 
the signal paths between 

the first station and the respective gateway device of the 

first cluster; and 
the second station and the respective gateway device of 

the second cluster 
are both radio frequency channels; and 
the nominated station 
uses control messages to control the appropriate use of 

a Radio Frequency channel in the first cluster and 
provides information to allow a nominated station in 

the second cluster to control the appropriate use of a 

Radio Frequency channel in the second cluster. 

19. A gateway device for use in a local communication 
system, the system including 

a plurality of stations interconnected for communicating 
messages via a first data bus and in accordance with a 
first set of communication protocols, and 

at least one further station not supporting said first set of 
communication protocols; and wherein 

said first set of communication protocols specifies a 
maximum time for reply by a first station to a message 
sent by a second station; 
said gateway device comprising 

means for linking said first data bus and said further 
station to enable communication therebetween, and 

means whereby when a message requiring a response is 
originated by a station of said plurality of stations and 
passed to said further station via said gateway, said 
gateway device (i) generates and sends a temporary 
response to the originating station within a predeter- 
mined period less than the specified maximum response 
time, pending arrival of a response from said further 
station, (ii) during said pendency, provides for passage 
of a message to or from another station of the plurality 
of stations, and (iii) upon arrival of said response from 
said further station, passes said response to said origi- 
nating station. 

* * * * * 
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(57) ABSTRACT 

A method of managing resources within a network for 
consumer electronic media devices. In one embodiment, the 
method is implemented as a software resource manager 
which provides a centralized resource allocation, reservation 
and access control functionalities for a home entertainment 
server. Particularly, user applications of the home server 
receive instructions from a user or other entities for a media 
service, and converts the instructions into a request that 
identifies the necessary resources for providing the media 
service. The software resource manager then determines 
whether such resources are available upon receiving the 
request. Importantly, the software resource manager also 
determines whether a routing path between the necessary 
resources has sufficient bandwidth for performing the 
requested media service. If necessary resources and band- 
width are available, the software resource manager then 
sends control signals to the source and destination devices 
causing them to perform the requested media services. 
Additionally, the software resource manager of the present 
invention provides event scheduling and request arbitration 
functionalities to the home entertainment server. In this 
manner, a secure home entertainment network that is pro- 
tected from misuse and abuse can thus be achieved. 

21 Claims, 6 Drawing Sheets 
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METHOD OF MANAGING RESOURCES channels for multiple video streams. Therefore, it would be 

WITHIN A NETWORK OF CONSUMER advantageous to provide a method of managing a network of 

ELECTRONIC DEVICES consumer electronic media devices. It would also be advan- 
tageous to provide a method of managing resources within 

FIELD OF THE INVENTION 5 a network of consumer electronic media devices such that 

The present invention pertains generally to the field of lhe problem of bandwidth contention is addressed, 

consumer electronic devices. More specifically, the present Yet another problem associated with a home entertain- 

invention pertains to the field of networked consumer elec- ment network is that, since media (e.g., CDs, DVDs) are 

tronic media devices. distributed across the network, it is burdensome for a user to 

10 locate the desired media. For example, a home entertainment 

BACKGROUND OF THE INVENTION network may include several DVD players and DVD juke- 

A home entertainment system typically includes a number boxes each ca P able of holdin & hundreds of DVDs. It would 
of consumer electronic media devices such as televisions, be dlfficu,t for a user to browse throu S h ever y devices t0 
compact disc (CD) players, tuners, digital video disc (DVD) locate the desired DVD * Therefore, it would be advanta- 
players, a video cassette recorders (VCRs) and high-fidelity 35 § eous t0 P r °vide a method of managing resources within the 
speakers. Many sets of wires are usually required to connect home network such that complicated management and con- 
these components together to provide the desired function- tro1 of lhe devices m hidden from the }}SGTS ' 
ality. For example, a set of wires is required for connecting Another problem associated with the home entertainment 
the DVD player to the TV and another set of wires is network is that, when connected to the Internet, the con- 
required for connecting the DVD player to the tuner. Yet sumer electronic devices and information contained therein 
another set of wires is required for connecting the tuner to may become compromised due to unauthorized access from 
the speakers. Most of these devices only have a limited third party users (e.g., hackers). Therefore, it would be 
number of inputs and outputs for connecting to other advantageous to provide a method of managing resources 
devices. Thus, it is not surprising that most home entertain- within the home network such that the devices are protected 
ment systems include only a handful of different devices. 2 from misuse and unauthorized accesses. 

Recently, a class of consumer electronic media devices 
has been introduced that can be networked together using a 
standard communication protocol layer (e.g., IEEE 1394 Accordingly, the present invention provides for an intel- 
communication standard). The IEEE 1394 standard is an 30 ligent centralized resource allocation, reservation and access 
international standard for implementing an inexpensive control system for a home entertainment network, 
high-speed serial bus architecture which supports both asyn- Furthermore, the present invention provides for a method of 
chronous and isochronous format data transfers. The IEEE managing resources within a home entertainment network 
1394 standard provides a high-speed serial bus for intercon- such that accesses to resources are granted based on access 
necting digital devices thereby providing universal input/ 35 rights associated with each resource. Applications attempt- 
output connection. The IEEE 1394 standard defines a digital ing to access the devices of the network must do so through 
interface for applications thereby eliminating the need for an a software resource manager. The present invention also 
application to convert digital data to an analog form before provides for a method of managing resources within the 
it is transmitted across the bus. Correspondingly, a receiving home entertainment network such that media -services can 
application will receive digital data from the bus, not analog 40 be delivered to a user without requiring the user to directly 
data, and will therefore not be required to convert analog control the devices. 

data to digital form. The IEEE 1394 standard is ideal for i n furtherance of the present invention, the home enter- 
consumer electronics communication in part because tainment network includes a plurality of consumer electronic 
devices can be added to or removed from the serial bus while me dia devices (e.g., Digital Video Disc Players, TVs, etc.) 
the bus is active. If a device is so added or removed, the bus 45 and a home entertainment server coupled together via high 
automatically reconfigures itself for transmitting data speed connections such as the IEEE 1394 bus. Particularly, 
between the then existing devices. Each device on the bus is user applications of home entertainment network have no 
a "node" and contains its own address space. direcl con trol over the devices. Rather, user applications can 

The provision of the IEEE 1394 serial communication bus only request the software resource manager, which has 

for networking consumer electronic devices has allowed the 50 complete control over all the devices, to provide the media 

development of a home entertainment network that consists service. The software resource manager then determines 

of a large number of consumer electronic devices. In whether the devices necessary for providing the media 

addition, the provision of the IEEE 1394 serial bus enables service are available. Importantly, the software resource 

a single source device to provide content to multiple desti- manager also determines whether a routing path between the 

nation devices. For example, a DVD player located in the 55 necessary devices has suflBcicnt bandwidth for providing the 

living room can be shared by multiple TV sets located in the requested media service. If necessary devices and bandwidth 

bedrooms and in the kitchen. However, one problem asso- are available, the software resource manager then sends 

ciated with sharing source devices within the home enter- control signals to the devices and causes them to provide the 

tainment network is that multiple users may want to use the requested media services. In this manner, resources of the 

same source devices at the same time. Therefore, it would be $ 0 nome entertainment network are hidden from the users and 

advantageous to provide an access control system that other user applications. Because the devices are isolated 

allocates control of the devices intelligently. from the user applications, a secure home entertainment 

Another problem associated with such a home entertain- network can also be achieved, 

ment network is bandwidth contention. For example, if In one embodiment of the present invention, the software 

many TV sets and DVD players are connected to the home 65 resource manager maintains a resource database for tracking 

network, the IEEE 1394 serial bus may not have sufficient availability of lhe consumer electronic devices of the home 

bandwidth to support multiple simultaneous isochronous e ntertainment network. Once a device is in-use, or otherwise 
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becomes unavailable, the device is removed from the 
resource database. When the device becomes available 
again, it is added to the resource database. In this way, the 
software resource manager can easily determine the avail- 
ability of the devices. The software resource manager further 5 
maintains a path database for tracking the availability of the 
routing paths between the devices. The path database stores 
all possible routing paths between all the devices and the 
bandwidth requirements for all the devices. With such 
information, the software resource manager can then readily 10 
determine whether the network can provide sufficient band- 
width to deliver the requested media service. 

In accordance with another embodiment of the present 
invention, the software resource manager provides a reser- 
vation database for storing resource reservation information. 15 
In this embodiment, the resource manager is configured for 
receiving a request for a future media service. The request is 
then stored within the reservation database. The home server 
of the present invention further provides a scheduler for 
scheduling the execution of the requested media service at a 20 
future time. 

These and others advantages of the present invention not 
specifically mentioned above will become clear within dis- 
cussions presented herein. 

25 

BRIEF DESCRIPTION OF THE DRAWINGS 

The accompanying drawings, which are incorporated in 
and form a part of this specification, illustrate embodiments 
of the invention and, together with the description, serve to 3Q 
explain the principles of the invention: 

FIG. 1 is a block diagram illustrating components of a 
home server in accordance with the present invention. 

FIG. 2 illustrates an exemplary home entertainment net- 
work in which embodiments of the present invention may be 35 
practiced. 

FIG. 3 is a logical block diagram of the software pro- 
cesses of a home server illustrated in FIG. 2 in accordance 
with the present invention. 

FIG. 4 is a data flow diagram illustrating the detailed 40 
communication protocol between user application and soft- 
ware resource manager illustrated in FIG. 3 in furtherance of 
the present invention. 

FIG. 5 is a flow diagram illustrating steps of the process 45 
of managing network resources according to an embodiment 
of the present invention. 

FIG. 6 is a'flow diagram illustrating steps of the process 
of reserving network resources according to an embodiment 
of the present invention. 50 

DETAILED DESCRIPTION OF THE 
PREFERRED EMBODIMENTS 

In the following detailed description of the preferred 
embodiments, for purposes of explanation, numerous spe- 55 
cific details are set forth in order to provide a thorough 
understanding of the present invention. However, it will be 
apparent to one skilled in the art that the present invention 
may be practiced without these specific details. In other 
instances, well-known structures and devices are not eo 
described in detail in order to avoid obscuring aspects of the 
present invention. 

I. COMPUTER SYSTEM ENVIRONMENT OF 
THE PRESENT INVENTION 

65 

Some portions of the detailed descriptions which follow 
are presented in terms of procedures, steps, logic blocks, 
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processing, and other symbolic representations of operations 
on data bits within a computer memory. These descriptions 
and representations are the means used by those skilled in 
the data processing arts to most effectively convey the 
substance of their work to others skilled in the art. A 
procedure, computer executed step, logic block, process, 
etc., is here and generally conceived to be a self-consistent 
sequence of steps of instructions leading to a desired result. 
The steps are those requiring physical manipulations of data 
representing physical quantities to achieve tangible and 
useful results. It has proven convenient at times, principally 
for reasons of common usage, to refer to these signals as 
bits, values, elements, symbols, characters, terms, numbers 
or the like. 

It should be borne in mind, however, that all of these and 
similar terms are to be associated with the appropriate 
physical quantities and are merely convenient labels applied 
to these quantities. Unless specifically stated otherwise as 
apparent from the following discussions, it is appreciated 
that throughout the present disclosure, discussions utilizing 
terms such as "collecting", "computing", "determining", 
"grouping", "mapping", "assigning" or the like, refer to the 
actions and processes of a computer system, or similar 
electronic computing device. The computer system or simi- 
lar electronic device manipulates and transforms data rep- 
resented as electronic quantities within the computer sys- 
tem's registers and memories into other data similarly 
represented as physical quantities within the computer sys- 
tem memories into other data similarly represented as physi- 
cal quantities within the computer system memories or 
registers or other such information storage, transmission, or 
display devices. 

Specific aspects of the present invention are operable 
within a home server system. In general, a home server (or 
other intelligent electronic device such as a set- top-box) for 
the home entertainment network in accordance with the 
present invention includes a general purpose computer sys- 
tem 101 operable as a platform to implement and support 
elements of the present invention. As shown in FIG. 1, 
computer system 101 includes an address/data bus 102 for 
communicating information including address, data, and 
control signals, a central processor 104 coupled with bus 102 
for processing information and instructions, a volatile 
memory 106 (e.g., random access memory RAM) coupled 
with the bus 102 for storing information and instructions for 
the central processor 104 and a non-volatile memory 108 
(e.g., read only memory ROM) coupled with the bus 102 for 
storing static information and instructions for the processor 
104, a data storage device 110 such as a magnetic or optical 
disk and disk drive coupled with the bus 102 for storing 
information and instructions, an optional display device 118 
coupled to the bus 102 for displaying information to the 
computer user, an optional alphanumeric input device 114 
including alphanumeric and function keys coupled to the bus 
102 for communicating information and command selec- 
tions to the central processor 104, an optional cursor control 
or directing device 116 coupled to the bus 102 for commu- 
nicating user input information and command selections to 
the central processor 104, and a communication device 112 
coupled to the bus 102 for communicating signals that are 
input and output from the system 101. The communication 
device 112 is configured for connecting to a home enter- 
tainment network via an IEEE 1394 serial communication 
bus 215. Computer 101 may further include another com- 
munication device (e.g., a modem) for connecting the home 
network to the Internet. 

Program instructions executed by the home server 101 
can be stored in computer usable memory units such as 
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RAM 106, ROM 108, or in the storage device 110, and when media (e.g., CDs, DVDs, video cassettes, etc.) to be distrib- 

executed in a group can be referred to as logic blocks or uted across the home network 200. Further, this feature 

procedures. It is appreciated that data produced at the enables the devices of the home entertainment network 200 

various stages of the present invention, including path to be distributed across the home, 

availability information and resource availability 5 

information, can also be stored in RAM 106, ROM 108 or HI. RESOURCE MANAGER ACCORDING TO 

the storage device 110 as shown in FIG. 1. THE PRESENT INVENTION 

The display device 118 of FIG. 1 utilized with the A feature of the present invention is that all resources of 
computer system 101 of the present invention is optional and a home entertainment network (e.g., devices, routing paths 
may be a flat panel liquid crystal display (LCD) device, a ™ between devices, etc.) are controlled and managed by a 
TV, a personal digital assistant (PDA) or other display software resource manager. According to one embodiment 
device suitable for creating graphic images and alphanu- of the present invention, a home network resource is defined 
meric characters recognizable to the user. The cursor control to be the physical devices that are capable of transporting, 
device 116 allows the computer user to dynamically signal housing, and displaying content. This means that if the 
the two dimensional movement of a visible pointer on a is device is actively generating content or controlling infor- 
display screen of the display device 118. Many implemen- rnation (via the device or a device proxy), the software 
tations of the cursor control device are known in the art resource manager is free to signal the device to stop pro- 
including a trackball, mouse, joystick or special keys on the ducing content or to redirect the content to another destina- 
alphanumeric input device 114 capable of signaling move- tion. 

ment of a given direction or manner of displacement. 20 ^ appUcation pfograms ^ web . browsers) 

II NETWORK ENVIRONMENT IN that USe ° r attem P t t0 use the resources are required to 

ACCORDANCE WITH THE PRESENT communicate with the software resource manager. 

INVENTION Generally, direct communication between the application 

25 programs and the devices or device proxies is not allowed. 
FIG. 2 illustrates an exemplary home entertainment net- An application program is only allowed to request the 
work 200 in which the present invention may be practiced. software resource manager to control the devices. By insert- 
Exemplary network 200 includes consumer electronic media ing a control layer between application programs and the 
devices (including computer systems) as nodes but could be device proxies, the devices will be protected against misuse 
extended equally well to cover other electronic devices. 3Q and abuse (e.g., unauthorized access or modification). 
Exemplary network 200 includes a digital video camera 210, Additionally, the software resource manager provides other 
a video cassette recorder (VCR) 212, a home server 214, a useful functions such as resource allocation and resource 
set-top-box 213, television sets (TVs) 211a-211c, a compact reservation. 

disc (CD) jukebox 220 and DVD players 222a-222fc con- FIG. 3 is a logical block diagram of the software pro- 

nected together by IEEE 1394-1995 (IEEE 1394) bus 215. 35 cesses of a home server 214 in accordance with the present 

The set-top-box 213 can be coupled to receive media from invention. As illustrated, software processes of home server 

a cable TV system. The IEEE 1394 bus lines, or "cables," 214 include a user application 310, a resource manager 320, 

allow the consumer electronic media devices to transmit a path database 330 and a resource pool 340. Software 

data, commands and parameters to other devices of the processes of the home server 214 further include a reserva- 

network 200. 4Q tion database 350 and a usage log 360. Home server 214 

It should be noted that home network 200 illustrated in further includes a plurality of software device proxies 

FIG. 2 is exemplary only and that an audio/video network in 370a-370/ each for controlling one of the devices of home 

accordance with the present invention could include many entertainment network 200. For example, software device 

different combinations of components. It should also be proxy 370c is for controlling TV 211c, and device proxy 

appreciated that consumer electronic devices of the network 45 3701 is for controlling VCR 212, etc., that are coupled to the 

200 may be accessed via user applications such as a web- IEEE 1394 bus interface 380, In one embodiment of the 

browser. present invention, the software device proxies 370 may 

The IEEE 1394 communication standard within network include HAVI Device Control Modules (DCMs) and Func- 

200 of FIG. 2 supports isochronous data transfers of digital tional Control Modules (FCMs). 

encoded information. Isochronous data transfers are real- 50 Significantly, according to the present invention, user 

time transfers which take place such that the time intervals application 310 is not allowed to communicate directly with 

between significant instances have the same duration at both software device proxies 370. Rather, user application 310 

the transmitting and receiving applications. Each packet of communicates to the resource manager 320 when it intends 

data transferred isochronously is transferred in its own time to access one of the network consumer electronic media 

period. An example of a "real-time" application for the 55 devices. Particularly, user application 310 receives instruc- 

transfer of data isochronously is from VCR 212 to TV 211a tions from a user or other entities for a media service, and 

of FIG. 2. The VCR 212 records images and sounds and converts the instructions into a request that identifies the 

saves the data in discrete packets. The VCR 212 then necessary resources for providing the media service. In the 

transfers each packet, representing the images and sounds following discusion, a media service is defined as content 

recorded over a limited time period, during that time period, 60 that is displayed or actions that are performed on behalf of 

for display by the TV 211a. The IEEE 1394 standard bus the users. For example, an external sensor triggering digital 

architecture provides multiple channels for isochronous data video camera 210 to capture video would be considered a 

transfers between applications. Specifically, a six bit channel media service. 

number is broadcast with the data to ensure reception by the In the present embodiment, the user application 310 of 

appropriate application. 'Itiis feature of the IEEE 1394 bus 65 FIG. 3 sends the request to the resource manager 320 in the 

allows multiple devices to simultaneously transmit isochro- form of an event list that indicates the source device, the 

nous data across the bus structure. This feature also enables destination device and the requested action. Thereafter, the 
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resource manager 320 determines the availability of the present invention, the Execute NowEvent request consists of 

source and destination devices, and checks whether suffi- information regarding the source device (Source ID), the 

cient bandwidth is available for carrying out the requested destination device (DestID) and the routing path between the 

action. If the devices and the bandwidth are available, the source device and the destination device (PathID). The 

resource manager 320 will return a "granted" signal and 5 ExecuteNowEvent request may further include information 

transmits the necessary control commands to the software such . as the identification of the user making the media 

device proxies 370a-370/. The software device proxies service request. 

370^-370/ then control the devices via IEEE 1394 bus At ste P 520 of FIG 5 > tne resource manager 320, upon 

interface 380. If the devices or the requisite bandwidth are receiving the ExecuteNowEvent request, looks up the 

not available, the resource manager 320 will return a 30 source .pool 330 and determines if the requested source 

"denied" signal to the user application 310. and desUnaUon devices are available. According to the 

T A 4| . ... . - present invention, the resource pool 330 is a list of all 

Importantfy according to the present invention, resource deyices connected (o ^ n6lwork F and ^ upon 

manager 320 allows the resources of home network 200 to initialization of the home ^ 210 ^ resource , 330 

be checked-in or checked-out independent of application fc also continuously updated to keep tackof devices that are 

requests. At any time, the resource manager 320 can reclaim 35 ^ ^ ^ from ^ ^ entertainment m± 

checked-out resources and reallocate them to other users. 1An Tf*u~ „ a a . a • i a • 

T , , . 200. II the source and destination devices are already ln-use 

Likewise, a reserved resource can be reclaimed and reallo- . *u _ r *■ «r\ * j» • i • 

„..,., by other users or user applications, a Denied signal is 

cated to other users or reallocate them back into the resource ' A . 4 . \. . . - rA ° 

oo j returned to the user application 310 at step 560. 

A " . 20 At step 530, the resource manager 320 looks up the path 

,™T™' n8 . t0 P resen V mventlon ' the resource mana S er database 340 to determine if there is sufficient bandwidth 

320 of FIG. 3, upon initialization of the home server 214, between the saam device and the destinatiorl devicet In lhe 

scans the home network 200 and determines all the available present embodiment, the path database 340 is a table for 

resources Data representative of the routing paths and their identifying the bandwidth requirements for all possible 

bandwidths are then stored within path database 330. Data routing palhs between lne devices M&ihods of calculating 

representative of the available devices are stored within and determining the bandwidth requirements for aU possible 

resource pool 340. As the resources of the home network rouling paths between the deyices are well lgDOWa in the ^ 

200 changes, the resource manager 320 modifies the path and m therefore, not describ ed herein to avoid obscuring 

database 330 and the resource pool accordingly. aspects ofthe present invention. If the resource manager 320 

User application 310 may also send a request for media 3Q determines that insufficient bandwidth is available, the 

services to be delivered at a future time. In the present resource manager 320 returns a "Denied" signal to the user 

embodiment, the request is in the form of a scheduled -event application 310 at step 560. If the requested resources are 

list. Particularly, the scheduled-event list may indicate the available, sends control signals to the device proxies 370 and 

time the scheduled-event is to be performed, and the nec- causes the devices to carry out the media service request 

essary routing paths and device information. The resource 35 immediately at step 540, and returns a "Granted" signal to 

manager 320, upon receiving the scheduled-event list, then the user application 310 at step 550. In addition, the source 

checks the reservation database 350 to determine whether devices and destination devices are removed from the 

the devices and the routing paths have already been reserved resource pool 330, and the path database is updated to reflect 

by other processes. If not, the resource manager 320 then the bandwidth usage at step 540. 

enters the devices and routing paths within the reservation 4Q FIG 6 Ls a flow diagrara illustrating the steps of a process 

database 350. The resource manager 320 also accesses a 600 for reserving network resources according to an 

scheduler (not shown) to schedule the future execution of embodiment of the present invention. The process 600 is 

the scheduled-event fist. described also in conjunction with FIG. 4. As illustrated, at 

Usage information of the network is stored within usage step 610, resource manager 320 receives an ScheduledEvent 

log 360 of FIG. 3. According to the present invention, every 45 request from the user application 310. According to the 

time a request for media service is granted, the event list is present invention, the ScheduledEvent request consists of 

stored within the usage log 360. The usage information can information regarding the source device (SourcelD), the 

be used to track warranty information of the devices. In destination device (DestID), the routing path between the 

addition, the usage information can be used to track the source device and the destination device (PathID) and the 

network usage of each user. The usage information may also 50 start time (StartTime) and end time (EndTime) of the sched- 

be used by the resource manager 320 for restricting access uled event. The ScheduledEvent request may further include 

to certain users who have exceeded their usage limitation. information such as the identification of the user making the 

FIG. 4 is a logical block diagram 400 illustrating the data media service request, 

flow between user application 310 and resource manager In another embodiment of the present invention, Sched- 

320 in accordance with the present invention. Data flows 55 uledEvent request may include two types of requests: 

between resource manager 320 and reservation database ExecuteWaliClockEvent and ExecuteCalendarEvent. The 

350, resource pool 330, path database 340, usage log 360 ExecuteWaliClockEvent request is for scheduling future 

and device proxies 370 are also illustrated. Resource man- execution of requests based on a 24-hr clock. The Execute- 

ager 320 stores device usage information within the usage CalendarEvent is for scheduling future execution of requests 

log 360. In addition, the resource manager 320 may send a 60 based on the calendar. For example, the Execute WallClock- 

Usagelnfo to the user application 310 when prompted. Event request is used for scheduling the recording of the 

FIG. 5 is a flow diagram illustrating the steps of a process "Evening News" at 6:00 pm in the evening everyday. As 

500 for managing network resources according an embodi- another example, the ExecuteCalendarEvent request is used 

ment of the present invention. The process 500 is described for scheduling the backing-up of the home computer system 

in conjunction with FIG. 4. As illustrated, at step 510, 65 every Sunday. 

resource manager 320 receives an ExecuteNowEvent At step 620 of FIG. 6, the resource manager 320, upon 

request from the user application 310. According to the receiving the ScheduledEvent request, looks up the reser- 
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vation database 350 and determines if the requested source 
and destination devices are available. If the source and 
destination devices are already reserved by other users or 
other user applications, an "Unavailable" signal is returned 
to the user application 310 at step 660. 5 

At step 630, the resource manager 320 looks up the path 
database 340 to determine if other reservations would affect 
the bandwidth of the routing path between the source device 
and the destination device at the request period. If the 
resource manager 320 determines that the routing path will 1° 
be affected, the resource manager 320 returns a Failure 
signal to the user application 310 at step 660. If it is 
determined that the routing path will not be affected, the 
resource manager 320 then stores the SourcelD, DestID, 
PathID, StartTime and EndTime within the reservation data- 15 
base 350 at step 640, and returns a "Reserved" signal to the 
user application 310 at step 650. 

IV. ADDITIONAL FEATURES OF THE 
RESOURCE MANAGER OF TIIE PRESENT 20 
INVENTION 
A Enforcing Access Restrictions 

The resource manager 320 of the present invention, when 
used in conjunction with other software processes of the 
home server 214 (e.g., Access Control Manager (ACM) and 25 
Media Binding Agent (MBA)), can be used for enforcing 
access restrictions. For instance, the ACM may provide user 
information (e.g., age of users) to the resource manager 320 
and the MBA may provide meta-infonnation (e.g., rating 
information) of the content of the requested media service to 30 
the resource manager 320. Access policies may be imple- 
mented within the user application 310 or the resource 
manager 320 to restrict access to the media contained within 
the devices even though the resources are available. For 
example, if an access policy may be implemented within 35 
resource manager 320 to prohibit users under age 13 from 
watching watch "R" rated movies. It is the responsibility of 
the resource manager 320 to enforce these access policies. 

B. Conflict Resolutions 

Another responsibility of the resource manager 320 is to 40 
perform conflict resolutions. If a user with a higher privilege 
wants to access a service originating from a single threaded 
device that is in use by another user with a lower privilege, 
the resource manager 320 attempts to resolve the conflict. It 
will send out a message informing the (source/destination) 45 
device is in use, and queries the more privileged user 
whether he/she desires to override the on-going service. A 
message notifying the user with the lower privilege may be 
sent indicating that their service is being terminated. When 
resources become available, the user with the lower privi- 50 
lege is free to re-reschedule the service. As long as there are 
limited resources and multiple service requests, only the 
service request with a higher priority will be serviced. In 
cases where multiple services with identical priorities 
request the same single threaded resources, a first come first 55 
serve policy will be observed. 

C. Resource Locking 

Another feature of the resource manager 320 is locking 
resources whereby users with lower privileges cannot access 
services and resources. For instance, a parent may prevent a 60 
specific category of music from playing in the home or may 
disallow TV viewing between the hours of 7:00 AM to 5:00 
PM. With this feature, the parent can allocate services to 
children based on time slots. For example, a child be allowed 
to watch TV for 10 hours a week. The child is free to spend 65 
the 10 hours anyway, he/she feels fit. Once the 10 hours are 
consumed, no more TV time is permitted. The parent may 
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put restrictions on the 10 hours of viewing time by prevent- 
ing certain channels from being viewed and disallowing 
certain viewing hours. 
D. Attribute Control 

Another feature of the resource manager 320 is to control 
specific attributes of a resource device once a service has 
started. An example of this feature is regulating volume 
controls for a music category (e.g., rap, rock, etc.). This can 
be done for specific locations in a home or for all locations. 
If a child's room is the designation location for "rap" music 
and the resource manager 320 has previously configured the 
child's room for volume control, when the rap music plays 
in that room the volume controls will be regulated. A parent 
may want such volume control to prevent base waves from 
reverberating throughout the house. The resource manager 
320 accomplishes this task by detecting the service category 
for the child's room and regulating volume control on the 
designation device. 

The attribute control functionality of the resource man- 
ager 320 may also be used to augment a service. For 
example, if a user is watching a horror movie in the family 
room, the resource manager 320 can draw the drapes and 
dim the lights (provided that the drape controls and the light 
controls are connected to the home network 200) while the 
movie is playing. As another example, if a telephone call is 
detected in the room where the movie is being viewed, the 
resource manager 320 can pause the movie and turn the 
lights on. 

The present invention, a computer implemented process 
for managing resources within a home entertainment 
network, has thus been described. By providing a centralized 
resource allocation and access control system, security of the 
home entertainment network can be achieved. While the 
present invention has been described in particular 
embodiments, it should also be appreciated that the present 
invention should not be construed as limited by such 
embodiments, but should be construed according to the 
below claims. 

What is claimed is: 

1. A method of managing resources within a network 
including a plurality of consumer electronic media devices, 
said method comprising the steps of: 

a) providing a resource manager for manging resources 
within said network; 

b) receiving a request for a media service, said request 
identifying a source consumer electronic media device 
and a destination consumer electronic media device 
that are necessary for performing said media service; 

c) based on said request, said resource manager deter- 
mining whether said source consumer electronic media 
device and said destination consumer electronic device 
are available for performing said media service; 

d) said resource manager determining whether a routing 
path between said source and said destination consumer 
electronic media devices has sufficient bandwidth for 
performing said media service; and 

e) provided said source electronic media device and said 
destination electronic media device are available and 
provided said routing path has sufficient bandwidth, 
said resource manager transmitting control signals to 
cause said plurality of consumer electronic media 
devices to provide said media service. 

2. The method as recited in claim 1 further comprising the 
step of returning a failure message provided said routing 
path does not have sufficient bandwidth for performing said 
media service. 
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3. The method as recited in claim 1 further comprising the 
steps of: 

constructing a list having a plurality of entries each 
corresponding to a respective one of said plurality of 
consumer electronic media devices; 5 

removing one of said entries from said list when a 
corresponding one of said plurality of consumer elec- 
tronic media devices becomes unavailable; and 

adding a new entry to said list when one of said plurality 
of consumer electronic media devices becomes avail- 
able. 

4. The method as recited in claim 1 further comprising the 
steps of: 

constructing a list having a plurality of entries each 15 
corresponding to a respective one of a plurality of 
routing paths connecting consumer electronic media 
devices of said network; 

determining bandwidth requirements for said routing 
paths of said network and generating data representa- 20 
tive thereof; and 

storing said data into a path database. 

5. The method as recited in claim 4 further comprising the 
steps of: 

removing one of said entries from said list when a 25 
corresponding one of said plurality of routing paths 
becomes unavailable; and 

adding a new entry to said list when said corresponding 
routing path becomes available. 3Q 

6. The method as recited in claim 1 further comprising the 
step of storing configuration information in a configuration 
database for each consumer electronic media device coupled 
to said network. 

7. The method as recited in claim 1 further comprising the 35 
steps of: 

storing resource reservation information into a reservation 
database; 

provided said media service is to be delivered in a later 
time, reserving said source consumer electronic media 40 
device, said destination consumer electronic media 
device and said routing path by adding an entry to said 
reservation database; and 

informing said network that said media service is unavail- 
able at said later time. 45 

8. A computer-usable medium having computer-readable 
program code embodied therein for causing a computer 
system to perform a method of managing resources within a 
network including a plurality of consumer electronic media 
devices, said method comprising the steps of: 50 

a) providing a resource manager for managing resources 
within said method; 

b) receiving a request for a media service, said request 
identifying a source consumer electronic media device 
and a destination consumer electronic media device 
that are necessary for performing said media service; 

c) based on said request, said resource manager deter- 
mining whether said source consumer electronic media 
device and said destination consumer electronic device 60 
are available for performing said media service; 

d) said resource manager determining whether a routing 
path between said source and said destination consumer 
electronic media devices has sufficient bandwidth for 
performing said media service; and 55 

e) provided said plurality of electronic media devices are 
available and provided said routing path has sufficient 
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bandwidth, said resource manager transmitting control 
signals to cause said plurality of consumer electronic 
media devices to provide said media service. 

9. The computer-usable medium as recited in claim 8 
wherein said method further comprises the step of returning 
a failure message provided said routing path does not have 
sufficient bandwidth for performing said media service. 

10. The computer-usable medium as recited in claim 8 
wherein said method further comprises the steps of: 

constructing a list having a plurality of entries each 
corresponding to a respective one of said consumer 
electronic media devices coupled to said network; 

removing one of said entries from said list when a 
corresponding one of said plurality of consumer elec- 
tronic media devices becomes unavailable; and 

adding a new entry to said list when one of said plurality 
of consumer electronic media devices becomes avail- 
able. 

11. The computer-usable medium as recited in claim 8 
wherein said method further comprises the steps of: 

constructing a list having a plurality of entries each 
corresponding to a respective one of a plurality of 
routing paths connecting consumer electronic media 
devices of said network; 

determining bandwidth requirements for said routing 
paths of said network and generating data representa- 
tive thereof; and 

storing said data into a path database, 

12. The computer-usable medium as recited in claim 11 
wherein said method further comprises the steps of: 

removing one of said entries from said list when a 
corresponding one of said plurality of routing paths 
becomes unavailable; and 

adding a new entry to said list when said corresponding 
routing path becomes available. 

13. The computer-usable medium as recited in claim 8 
wherein said method further comprises the step storing 
configuration information into a configuration database for 
each consumer electronic media device coupled to said 
network. 

14. The computer-usable medium as recited in claim 8 
wherein said method further comprises the steps of: 

storing resource reservation information into a reservation 
database; 

provided said media service is to be delivered in a later 
time, reserving said source consumer electronic media 
device, said destination consumer electronic media 
device and said routing path by adding an entry to said 
reservation database; and 

informing said network that said media service is unavail- 
able at said later time. 

15. A home server comprising: 
a processor; 

a bus coupled to said processor; and 

a computer readable memory coupled to said bus and 
having stored therein computer readable program code 
for causing said home server to perform a method of 
managing resources within a network including a plu- 
rality of consumer electronic media devices, said home 
server, said method comprising the steps of: 

a) providing a resource manager for managing resources 
of said network; 

b) receiving a request for a media service, said request 
identifying a source consumer electronic media device 


04/02/2004, EAST Version: 1.4.1 


US 6,363,434 Bl 


13 


14 


and a destination consumer electronic media device 
coupled to said network that are necessary for perform- 
ing said media service; 

c) based on said request, said resource manager deter- 
mining whether said source consumer electronic media 5 
device and said destination consumer electronic device 
are available for performing said media service; 

d) said resource manager determining whether a routing 
path between said source and said destination consumer 
electronic media devices has sufficient bandwidth for 30 
performing said media service; and 

e) provided said plurality of electronic media devices are 
available and provided said routing path has sufficient 
bandwidth, said resource manager transmitting control 
signals to cause said plurality of consumer electronic 
media devices to provide said media service. 

16. The home server as recited in claim 15 wherein said 
method further comprises the step of returning a failure 
message provided said routing path does not have sufficient 
bandwidth for performing said media service. 

17. The home server as recited in claim 15 wherein said 
method further comprises the steps of: 

constructing a list having a plurality of entries each 
corresponding to a respective one of consumer elec- 2 s 
tronic media devices coupled to said network; 

removing one of said entries from said list when a 
corresponding one of said plurality of consumer elec- 
tronic media devices becomes unavailable; and 

adding a new entry to said list when one of said plurality 30 
of consumer electronic media devices becomes avail- 
able. 

18. The home server as recited in claim 15 wherein said 
method further comprises the steps of: 


20 


constructing a list having a plurality of entries each 
corresponding to a respective one of a plurality of 
routing paths connecting consumer electronic media 
devices of said network; 

determining bandwidth requirements for said routing 
paths of said network and generating data representa- 
tive thereof; and 

storing said data in a path database. 

19. The home server as recited in claim 18 wherein said 
method further comprises the steps of: 

removing one of said entries from said list when a 
corresponding one of said plurality of routing paths 
becomes unavailable; and 

adding a new entry to said list when said corresponding 
routing path is becomes available. 

20. The home server as recited in claim 15 wherein said 
method further comprises the step of storing configuration 
information into a configuration database for each consumer 
electronic media device coupled to said network. 

21. The home server as recited in claim 15 wherein said 
method further comprises the steps of: 

storing resource reservation information into a reservation 
database; 

provided said media service is to be delivered in a later 
time, reserving said source consumer electronic media 
device, said destination consumer electronic media 
device and said routing path by adding an entry to said 
reservation database; and 

informing said network that said media service is unavail- 
able at said later time. 
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ABSTRACT 


Interoperability is facilitated between two networks. One 
method according to the present invention comprises: pro- 
viding a VHN network having a VHN element; providing a 
HAVi network having a HAVi element; translating messages 
via a protocol translator coupled with the VHN network and 
the HAVi network; wherein interoperability is facilitated 
between the HAVi element and the VHN element. 
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HAVI-VHN BRIDGE SOLUTION 

CROSS-REFERENCES TO RELATED 
APPLICATIONS 

[0001] This invention derives priority from U.S. Provi- 
sional Patent Application No. 60/181,406, filed Feb. 9, 2000 
and entitled "HAVi-VHN Bridge Solution " which is incor- 
porated herein in its entirety for all purposes. 

BACKGROUND OF THE INVENTION 

[0002] A typical home audio/video (AV) equipment set-up 
includes a number of components. For example, a radio 
receiver, a compact disc (CD) player, a pair of speakers, a 
television (TV), a video cassette recorder (VCR), a tape 
deck and the like. Each of these components are connected 
to each other via a set of wires. One component is usually 
the central component of the home AV system. This is 
usually the radio receiver or the tuner of the radio receiver. 
The tuner has a number of specific inputs for coupling the 
other components. The tuner has a corresponding number of 
control buttons or control switches which provide a limited 
degree of controllability and interoperability for the com- 
ponents. The control buttons and control switches are usu- 
ally located on the front of the tuner. In many cases, some 
or all of these buttons and switches are duplicated on a 
hand-held remote control unit. A user controls the home AV 
system by manipulating the buttons and switches on the 
front of the tuner, or alternatively, manipulating buttons on 
the hand-held remote control unit. 

[0003] This conventional home AV system paradigm has 
become quite popular. As consumer electronic (CE) devices 
become more capable and more complex, the demand for the 
latest and most capable devices has increased. As new 
devices emerge and become popular, the devices are pur- 
chased by consumers and "plugged" into their home AV 
systems. Generally, the latest and most sophisticated of these 
devices are quite expensive (e.g., digital audio tape record- 
ers, digital video disc (DVD) players, digital camcorders and 
the like). As a consumer purchases new devices, most often, 
the new device is simply plugged into the system alongside 
the pre-existing, older devices (e.g., cassette tape deck, CD 
player and the like). The new device is plugged into an open 
input on the back of the tuner, or some other device coupled 
with the tuner. The consumer (e.g., the user) controls the 
new device via the control buttons on the tuner, via the 
control buttons and control switches on the front of the new 
device itself, or via an entirely new, separate, respective 
remote control unit for the new device. 

[0004] As the number of new CE devices for the home AV 
system has grown and as the sophistication and capabilities 
of these devices have increased, a number of problems with 
the conventional paradigm have emerged. One such problem 
is incompatibility between devices in the home AV system. 
CE devices from one manufacturer often couple with an AV 
system in a different manner than similar devices from 
another manufacturer. For example, a tuner made by one 
manufacturer may not properly couple with a TV made by 
another manufacturer. 

[0005] In addition, where one device is much newer than 
another device additional incompatibilities may exist. For 
example, a new device might incorporate hardware (e.g., 
specific inputs and outputs) which enables more sophisti- 


cated remote control functions. This hardware may be 
unusable with older devices within the system. As another 
example, older tuners may lack suitable inputs for some 
newer devices (e.g., mini -disc players, VCR's, etc.), or may 
lack enough inputs for all devices of the system. 

[0006] Another problem is the lack of functional support 
for differing devices within the home AV system. For 
example, even though a TV may support advanced sound 
formats (e.g., surround sound, stereo, etc.), if an older less 
capable tuner does not support such functionality, the ben- 
efits of the advanced sound formats can be lost. 

[0007] Yet another problem is the proliferation of controls 
for the new and differing devices within the home AV 
system. For example, similar devices from different manu- 
facturers can each have different control buttons and control 
switch formats for accomplishing similar tasks (e.g., setting 
the clock on a VCR, programming a VCR to record a 
program, and the like). In addition, each new device coupled 
with the AV system often leads to another dedicated remote 
control unit for the user to keep track of and leam to operate. 

[0008] Standards have been developed for the home AV 
system which aim to correct the interoperability and func- 
tionality problems of the conventional system. These stan- 
dards include the Home Audio/Video Interoperability 
(HAVi) Architecture and the Video Electronics Standards 
Association (VESA) Home Network, or VHN. 

SUMMARY OF THE INVENTION 

[0009] In an embodiment of a method according to the 
present invention, interoperability is facilitated between two 
networks. The method comprises: providing a VHN network 
having a VHN element; providing a HAVi network having 
a HAVi element; translating messages via a protocol trans- 
lator coupled with the VHN network and the HAVi network; 
wherein interoperability is facilitated between the HAVi 
clement and the VHN element 

[0010] In an embodiment of a method according to the 
present invention, interoperability is facilitated between two 
networks. 'Hie method comprises: providing a VHN network 
having a VHN element; providing a HAVi network having 
a HAVi element; providing a protocol translator coupled 
with the VHN network and the HAVi network; and control- 
ling the at least one VHN element with the at least one HAVi 
element. 

[0011] In an embodiment of a computer- readable media 
according to the present invention, interoperability is facili- 
tated between a VHN network having a VHN element and 
a HAVi network having a HAVi element. The computer- 
readable media comprises: providing instructions for cou- 
pling the VHN network with the HAVi network; and pro- 
viding instructions for facilitating interoperability between 
the HAVi element and the VHN element. 

[0012] In an embodiment of a system according to the 
present invention, interoperability is facilitated between two 
networks. The system comprises: a VHN network having a 
VHN element; a HAVi network having a HAVi element; and 
a protocol translator coupled with the VHN network and the 
HAVi network; wherein the protocol translator facilitates 
interoperability between the HAVi element and the VHN 
element. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

[0013] FIG. 1 is an illustration of a computer system 
suitable for use with the present invention, 

[0014] FIG. 2 shows subsystems in the computer system 
of FIG. 1. 

[0015] FIG. 3 depicts the arrangement of software ele- 
ments on a HAVi FAV device. 

[0016] FIG. 4 is a basic VHN device-to-device control 
model. 

[0017] FIG. 5 illustrates a VHN network coupled with a 
HAVi network. 

[0018] FIG. 6 illustrates FIG. 5 in greater detail. 

[0019] FIG. 7 is a flow diagram of a new device being 
plugged into a HAVi network. 

[0020] FIG. 8 is a flow diagram of a VHN application 
controlling a HAVi device. 

[0021] FIG. 9 is a flow diagram of a VHN application 
controlling a HAVi application. 

[0022] FIG. 10 is a flow diagram of a VHN device 
controlling a HAVi device. FIG. 10 is also a flow diagram 
of a VHN device controlling a HAVi application. 

[0023] FIG. 11 is a flow diagram of a HAVi application 
controlling a VHN device. 

[0024] FIG. 12 is a flow diagram of a HAVi application 
controlling a VHN application. 

[0025] FIG. 13 is a flow diagram of a HAVi device 
controlling a VHN device. 

[0026] FIG. 14 is a flow diagram of a HAVi device 
controlling a VHN application. 

DESCRIPTION OF THE SPECIFIC 
EMBODIMENTS 

[0027] As shown in the exemplary drawings wherein like 
reference numerals indicate like or corresponding elements 
among the figures, an embodiment of a system according to 
the present invention will now be described in detail. The 
description describes an exemplary apparatus suitable to 
implement an embodiment of the present invention. Meth- 
ods of operation and associated user interface details in 
accordance with the invention are also provided. 

[0028] FIG. 1 shows a computer system 100 suitable for 
use to provide a system in accordance with the present 
invention. The computer system 100 includes a display 102 
having a display screen 104 (the display may be a digital 
television (DTV) or personal digital assistant (PDA)-like 
device, etc.). A cabinet 106 houses standard computer com- 
ponents (not shown) such as a disk drive, CD-ROM drive, 
display adapter, network card, random access memory 
(RAM), central processing unit (CPU) and other compo- 
nents, subsystems and devices (since these inventions talk 
about a home network, 106 may be a STB (set top box) and 
not a standard PC). User input devices such as a mouse 108 
having buttons 110, and a keyboard 112 are shown (another 
input device may be a two-way remote controller, a PDA- 
like device or a Sony Airboard device). Other user input 
devices such as a trackball, touch-screen, digitizing tablet, 


etc., can be used. In general, the computer system 100 is 
illustrative of one type of computer system, such as a 
desktop computer, suitable for use with the present inven- 
tion. Computers can be configured with many different 
hardware components and can be made in many dimensions 
and styles (e.g., laptop, palmtop, server, workstation and 
mainframe). Thus, any hardware platform suitable for per- 
forming the processing described herein is suitable for use 
with the present invention, 

[0029] FIG. 2 illustrates subsystems found in the com- 
puter system 100. Subsystems within box 106 are directly 
interfaced to an internal bus 210. The subsystems include 
input/output (I/O) controller 212, system random access 
memory (RAM) 214, central processing unit (CPU) 216, 
display adapter 218, serial port 220, fixed disk 222, network 
interface adapter 224 and transceiver 230. The use of the bus 
allows each of the subsystems to transfer data among the 
subsystems and, most importantly, with the CPU. External 
devices can communicate with the CPU or other subsystems 
via the bus by interfacing with a subsystem on the bus. The 
monitor 104 connects to the bus through the display adapter 
218. A relative pointing device (RPD) such as a mouse 108 
connects through the serial port. Some devices such as 
keyboard 112 can communicate with the CPU by direct 
means without using the main data bus as, for example, via 
an interrupt controller and associated registers (not shown). 
The transceiver 230 can be coupled with a satellite system, 
cable system, telephone lines or any other system suitable 
for propagating information. The transceiver can include or 
be coupled with a communication interface, which can be 
coupled with bus 210. 

[0030] FIG. 2 is illustrative of one suitable configuration 
for providing a system in accordance with the present 
invention. Subsystems, components or devices other than 
those shown in FIG. 2 can be added without deviating from 
the scope of the invention. A suitable computer system can 
also be achieved without using all of the subsystems shown 
in FIG. 2. Other subsystems such as a CD-ROM drive, 
graphics accelerator, etc., can be included in the configura- 
tion without affecting the performance of the system 
included in the present invention. 

[0031] The invention is related to the use of apparatus, 
such as the computer system 100, for implementing a 
scalable pay-by-time technique for the secure multicast 
distribution of streaming content, including, but not limited 
to, video and audio. According to one embodiment of the 
invention, multicast distribution is provided by the computer 
system 100 in response to the processor 216 executing one 
or more sequences of one or more instructions contained in 
the system memory 214. Such instructions may be read into 
memory 214 from a computer-readable medium, such as a 
fixed disk 222. Execution of the sequences of instructions 
contained in the memory 214 causes the processor to per- 
form the process steps described herein. One or more 
processors in a multi-processing arrangement may also be 
employed to execute the sequences of instructions contained 
in the memory. In alternative embodiments, hard-wired 
circuitry may be used in place of or in combination with 
software instructions to implement the invention. Thus, 
embodiments of the invention are not limited to any specific 
combination of hardware circuitry and software. 

[0032] The terms "computer-readable medium" and 
"computer-readable media" as used herein refer to any 
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medium or media that participate in providing instructions to 
the processor 214 for execution. Such media can take many 
forms, including, but not limited to, non-volatile media, 
volatile media and transmission media. Non-volatile media 
include, for example, optical or magnetic disks, such as a 
fixed disk 222. Volatile media include dynamic memory, 
such as memory 214. Transmission media include coaxial 
cables, copper wire and fiber optics, including the wires that 
comprise the bus 210. Transmission media can also take the 
form of acoustic or light waves, such as those generated 
during radio frequency (RF) and infra-red (IR) data com- 
munications. Common forms of computer-readable media 
include, for example, a floppy disk, a flexible disk, a hard 
disk, magnetic tape, any other magnetic medium, a CD- 
ROM disk, DVD, any other optical medium, punch cards, 
paper tape, any other physical medium with patterns of 
holes, a RAM, a PROM, an EPROM, a FLASH-EPROM, 
any other memory chip or cartridge, a carrier wave as 
described hereinafter, or any other medium from which a 
computer can read. 

[0033] Various forms of computer-readable media may be 
involved in carrying one or more sequences of one or more 
instructions to processor 216 for execution. For example, the 
instructions may initially be borne on a magnetic disk of a 
remote computer. The remote computer can load the instruc- 
tions into its dynamic memory and send the instructions over 
a telephone line using a modem. A modem local to the 
computer system 100 can receive the data on the telephone 
line and use an infrared transmitter to convert the data to an 
infrared signal. An infrared detector coupled with the bus 
210 can receive the data carried in the infrared signal and 
place the data on the bus. The bus carries the data to the 
memory 214, from which the processor retrieves and 
executes the instructions. The instructions received by the 
memory can optionally be stored on the fixed disk 222 either 
before or after execution by the processor. 

[0034] The computer system 100 also includes a network 
interface 224 or communication interface coupled to the bus 
210. The network interface or communication interface 
provides a two-way data communication coupling with a 
network link 234 that is connected to a local network 236. 
For example, the network interface or communication inter- 
face can be an integrated services digital network (ISDN) 
card or a modem to provide a data communication connec- 
tion to a corresponding type of telephone line. As another 
example, the network interface or communication interface 
can be a local area network (LAN) card to provide a data 
communication connection to a compatible LAN. Wireless 
links can also be implemented. In any such implementation, 
the network interface 224 or the communication interface 
and transceiver 230) send and receives electrical, electro- 
magnetic or optical signals that carry digital data streams 
representing various types of information. 

[0035] The network link 234 typically provides data com- 
munication through one or more networks to other data 
devices. For example, the network link can provide a 
connection through the local network 236 to a host computer 
or to data equipment operated by an Internet Service Pro- 
vider (ISP). The ISP in turn provides data communication 
services through the worldwide packet data communication 
network, now commonly referred to as the "Internet." The 
local network and the Internet both use electrical, electro- 
magnetic or optical signals that carry digital data streams. 


The signals that propagate through the various networks and 
the signals on the network link and that propagate through 
the network interface 224, and the signals that propagate 
through the transceiver 230, which carry the digital data to 
and from computer system 100, are exemplary forms of 
carrier waves transporting the information. 

[0036] The computer system 100 can send messages and 
receive data, including user commands, video data, audio 
data and program codes through the network(s), the network 
link 234, and the network interface 224. In the Internet 
example, a server might transmit a requested code for an 
application program through the ISP, Internet, local network 
236 and network interface 224. Instead of or in addition to 
transmission via the Internet, the computer system 100 can 
send and receive data via the transceiver 230 and a wireless 
system, satellite system, cable system, telephone lines or any 
other system suitable for propagating information between 
the computer system and an information distribution system. 
In accordance with the invention, one such downloaded 
application provides for a scalable pay-by-time technique 
for secure multicast distribution of streaming content as 
described herein. The processor 216 can execute the 
received code as the code is received, and/or store the code 
on the fixed disk 222, or other non-volatile storage for later 
execution. In this manner, the computer system can obtain 
an application code in the form of a carrier wave. 

[0037] It is contemplated that various hardware compo- 
nents can be added to the present system. Some examples of 
these components include set-top boxes, interactive televi- 
sions and mobile devices, 

[0038] Unless specifically stated otherwise or apparent 
from the following discussion, one should appreciate that 
terms such as "computer,""compute,""computed,""compu- 
ting/ n< processor/* u process,""processed ,H *processing, 
""memory" or the like, can refer to the parts, actions and 
processes of an intelligent device such as a computer system - y 
set -top box, digital television or the like. Moreover, the 
computer system 100 can refer to any CE device that 
provides a computer system platform. Some examples of 
such CE devices include set-top boxes (STB's), DTV's, 
general purpose home control devices and personal com- 
puters (PC's), which are known in the art. 

[0039] The HAVi architecture, mentioned above, is 
intended for implementation on computing devices and CE 
devices. HAVi, which is known in the art, provides a set of 
services which facilitate interoperability and the develop- 
ment of distributed applications on home networks. HAVi is 
a software architecture that allows new devices to be inte- 
grated into the home network and to offer their services in 
an open and seamless manner. The types of devices sup- 
ported by HAVi include, but are not limited to: DTV, set-top 
box, DVD, tuner, VCR, clock, camera, AV disc, display, 
amplifier, modem, Web proxy and converter. HAVi devices 
are Institute of Electrical and Electronics Engineers (IEEE) 
1394 enabled. 

[0040] Referring to FIG. 3, the arrangement of software 
elements 100 on a HAVi Full AV (FAV) Device is depicted. 
Collectively, these software elements expose the Interoper- 
ability Application Programming Interface (API), a set of 
services for building portable distributed applications on the 
home network. The following is a general description of the 
HAVi Architecture. The Audio/Video Operating System 
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(AVOS) 102 is a portability layer on top of the vendor- 
specific platform 104 (e.g., RTOS or Windows CE). The 
AVOS acts as a portability layer by allowing a change of 
vendor platform without the need to rewrite the upper layer 
applications 106 and middleware 108. Below the vendor- 
specific platform lie the 1394 device drivers 110 and other 
device drivers 112. 

[0041] When an application in a HAVi environment wants 
to find out about what kind of network devices or network 
services are available, the application goes to the registry 
114. Software elements describe themselves to the registry. 
Applications can go to the registry to find out what those 
software elements are. It is a way to implement discovery. 
The stream manager 116 is responsible for setting up 
streams of data. For example, the stream manager may 
stream video from a hard disc drive to a TV. 

[0042] The resource manager 118 is responsible for sched- 
uling resources. For example, tells devices when to turn on 
or off, or to play loudly or softly. Basically, the function of 
a resource manager is analogous to that of a conductor of a 
symphony. The event manager 120 acts as an event mecha- 
nism. An application may be interested in when an asyn- 
chronous event occurs. The event manager generates an 
event at appropriate times (e.g., when a TV turns on or off). 

[0043] The messaging system 122 is a conduit for mes- 
sages to be passed through. The messaging system commu- 
nicates with the event manager 120, the stream manager 116 
and device control modules (DCM's) 124. DCM's are 
conceptually central to the HAVi architecture and the source 
of flexibility in accommodating new features and devices. 
DCM's act as software proxies. There is one DCM present 
in a HAVi system per device. In order to communicate with 
a given device, an application or other device communicates 
with the DCM, which in turn communicates with the given 
device using the appropriate protocol proprietary to the 
given device. 

[0044] The DCM manager 126 is responsible for loading, 
instantiating and removing DCM's 124 from the system. 
The DCM manager oversees the installation and removal of 
DCM's. For, example, if a system included a TV, a hard 
drive and two set-top boxes, the DCM manager would 
determine on which the devices the various DCM's would 
run. The DCM manager would load the byte code from the 
configuration ROM of the BAV devices and create DCM's 
within one or both of the set-top boxes. There would only be 
one DCM created per device that is going to be controlled. 
The DCM manager oversees the DCM installation and 
makes sure that only one DCM is running per device that is 
going to be controlled. The DCM manager decides which 
FAV or LAV device stores each DCM. 

[0045] Intermediate AV devices (IAV's) and Base AV 
devices (BAV's) arc also part of a typical HAVi system, IAV 
devices are generally lower in cost than FAV devices and 
more limited in resources. IAV devices do not provide a 
runtime environment for Java bytecode and so cannot act as 
controllers for arbitrary devices within the home network. 
However, an IAV may provide native support for control of 
particular devices on the home network. 

[0046] A BAV device is a "dumb" device (e.g., a printer) 
that provides uploadable Java bytecode, but does not host 
any of the software elements of the HAVi architecture. The 


control information for the BAV device is stored on con- 
figuration read-only memory (ROM) within the device. This 
information relates to how to control the BAV device and 
how it talks to other BAV devices can be controlled by an 
FAV device via the uploadable bytecode or from an IAV 
device via native code. The protocol between the BAV 
device and the BAV software proxy may or may not be 
proprietary. Communication between an FAV or IAV device 
and a BAV device requires that HAM commands be trans- 
lated to and from the command protocol used by the BAV 
device. 

[0047] A device (e.g., TV, camera, set-top box, stereo 
system, MP3 player) can be controlled (e.g., turn on, turn 
off, play, fast-forward) by commands. Those commands can 
be in Java bytecode, which can live inside the configuration 
ROM of the device itself. The DCM manager 126 reads the 
byte code in the configuration ROM of a BAV device and 
creates the DCM for the BAV device. When an entity tells 
the DCM to, say, power on, the DCM tells the corresponding 
device to power on. The DCM sends a control sequence (a 
command packet) over an IEEE 1394 bus, wireless connec- 
tion, etc. 

[0048] The function of the 1394 communication media 
manager (CMM) 128 is to manage communications and put 
the bits on the wires. In use, when a CE device is plugged 
into the HAVi network, the network creates a bus reset and 
sends this signal on the 1394 bus to all devices on the bus. 
The CMM detects the bus reset and sends a new CE device 
event to the DCM manager 126. This happens through the 
event manager 120. Any device can register with the event 
manager and will subsequently be informed when a new 
device is on the bus. The CMM then reads the configuration 
ROM and retrieves a DCM code unit. The CMM causes the 
code unit to install the DCM 124. Subsequently, the DCM 
124 registers with the messaging system 122 and the registry 
114. 

[0049] A HAVi application 106 that has initialized itself 
and is running registers with the messaging system 122 so 
that it can communicate with other processes. The event 
manager 120 notifies a HAM application that is running of 
a new device on the bus. The HAVi application can go to the 
registry 114 to find out if there is a device that it wants to 
control (e.g., VCR, TV, etc.). Let us assume the application 
is looking for a VCR to control. The application may find the 
VCR and gets the software handle from the registry. The 
application is now able to communicate with the DCM for 
the VCR. The HAVi application module can talk to the 
resource manager 118 and give instructions to, for example, 
turn on the VCR at 10:00 p.m. and record. 

[0050] Furthermore, the DCM manager 126 is notified by 
the event manager 120 that there is a new device on the bus. 
The DCM manager reads the profile in the configuration 
ROM and reads the self-describing data (SDD) to find out 
what the device is. The DCM manager decides on a DCM 
host for the DCM of the new device and then loads the 
DCM. The HAVi application 106 may do discovery and go 
into the registry 114 and discover the new DCM was loaded. 
The HAVi application may then decide to control the new 
device (e.g., set the clock on the device, the device being a 
VCR). 

[0051] The VHN architecture, mentioned above, allows 
for the recognition and interoperability of multiple home 
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network devices. This interoperability enables consumers to 
access all their networked appliances through devices such 
as their PC or TV. VHN utilizes Internet technologies to 
seamlessly connect all home devices, while providing 
remote device control using any Web browser. Using Inter- 
net protocols, the VHN network provides the capability to 
couple different network technologies together under one 
completely supported system. 

[0052] A graphical user interface (GUI) for a VHN system 
may consist of a plurality of icons displayed on a computer 
or TV screen. When a user selects an icon, the HTML pages 
are retrieved from the configuration ROM of the device in 
question. The HTML pages are displayed for the user. This 
allows the user to control the given device. 

[0053] Referring to FIG. 4, a basic VHN device-to-device 
control model is shown. The figure shows a controller 
module 400 and a controlled module 402. The controller 
module can discover the controlled module and control the 
services 404 of the controlled module. The controlled appli- 
cation component 406, an embedded executable software in 
the controlled module, has direct control over the services. 
The controlled module application interface 408 describes 
the controllable services and interface of the controlled 
application component. 

[0054] If a device-to-device control process is triggered, 
the controller module 400 will first attempt to discover the 
controlled module 402. After the controller module has 
discovered the interface of the controlled module, it can send 
commands thereto. This generates an acknowledgment and/ 
or machine action of the services 404. VHN allows the use 
of Web technology (XML) for the message and interface 
formats. A home network broker and interface repository 
(HNB & IR) can be located in any third device, or in a 
separate, dedicated device. The HNB & IR is a software 
agent that helps one device discover other devices and what 
their commands are, among other things. 

[0055] When a device first comes online it registers with 
the HNB & IR, revealing the type of device it is and the 
commands that the device supports. If the controller module 
400 wants to control the controlled module 402, the con- 
troller module first has to go through discovery. Therefore, 
the controller module reads the HNB & IR and discovers the 
controlled module (e.g., that of a VCR) and also the com- 
mands it needs to communicate with or control the VCR. 
The controller module obtains the handle (IP address) for the 
controlled module. The controller module can now talk to 
the VCR and send commands through an XML-based 
remote procedure call (RPC). 

[0056] In accordance with embodiments of the present 
invention, FIG. 5 illustrates a network 500 comprising a 
VHN network 502 and a HAVi network 504. The VHN 
network and the HAVi network each comprise at least one 
element. The elements can include devices and application. 
Interoperability is facilitated between the VHN network and 
the HAVi network by providing a protocol translator 506 
coupled with the VHN network and the HAVi network, all 
of which are coupled to an IEEE 1394 bus 508 or other 
suitable bus. The protocol translator 506 can physically or 
logically be on the some device as the HAVi controller 504. 
The protocol translator, or bridge, allows for controlling a 
HAVi element (device or application) with a VHN element 
(device or application). 


[0057] Turning now to FIG. 6, FIG. 5 is shown in greater 
detail. A VHN bridge control manager (VBCM) 600, does 
handshaking and protocol conversion between the HAVi and 
VHN networks. The HAVi bridge control manager (HBCM) 
602, talks to the HNB & IR 604 in behalf of the HAVi 
network. The HBCM 602 and the VBCM 600 together 
comprise the protocol translator 506, converting HAVi mes- 
sages into XML messages and converting XML messaging 
into HAVi messages (as well as other things). The HAVi- 
VHN DCM's 610, 618 (described below) may or may not be 
considered a part of the protocol translator. The HNB & IR 
knows which devices are on the VHN network and the HAVi 
network providing the VBCM is fully operational. Likewise, 
the HAVi registry knows which devices are on the HAVi 
network and the VHN network providing the HBCM is fully 
operational. In order for this to happen it is up to individual 
VHN devices to inform the HNB & IR of its presence in the 
VHN network and individual HAVi devices to inform the 
HAVi registry of its presence in the HAVi network. Other- 
wise the HNB & IR and HAVi registry will not know when 
devices come, go and change state. The HBCM constantly 
monitors the HNB & IR for new VHN devices so that the 
HAVi network 504 can know when to instantiate the respec- 
tive HAVi- VHN DCM and it can register the VHN device 
with the HAVi registry. If a VHN device is removed from the 
network, the HBCM will notify the VBCM which will in 
turn remove the respective HAVi- VHN DCM. This is done 
to free memory. 

[0058] As shown in FIG. 7, when a new device, such as 
hard disc drive (HDD) 606 or DVD player 608, comes on the 
HAVi network 504 (step S700), a bus reset is generated. At 
S702, the DCM manager loads the HAVi DCM, and the 
DCM instantiates itself. At S704, the DCM (and correspond- 
ing FCMs) registers with the HAVi messaging system and 
the registry 114. At S706, the HAVi event manager 120 
notifies the VBCM 600 of the event (the new DCM). At 
S708, the VBCM instantiates the HAVi- VHN device DCM 
and sends a message to the HBCM 602. The HBCM 
configures the new HAVi device into the VHN network and 
returns an IP address to the VBCM (the IP address will be 
used to reference the HAVi device in the VHN network). The 
returning of the IP address signifies that the HBCM suc- 
cessful configured the HAVi device in the VHN network. 
The VBCM uses the IP address in the protocol conversion 
and passes it to the HAVi-VHN device DCM. 

[0059] Turning to FIG. 8, al step S800, after a DVD 608 
is connected, a user from the VHN network can access the 
HAVi DVD device. This discover occurs by accessing the 
HNB & IR 604. Control of the DVD player is through the 
VHN application's Web browser 615 and accessing the 
VHN BCM, and the device application 617. The Web client 
pulls the HTML page out and HAVi-VHN DCM, thereby 
allowing the user to control the DVD player. At step S802, 
the user selects a "play" icon on the DTV 616. At step S804, 
the play command is encoded in XML and sent to the 
VBCM 600. At step S806, the VBCM in turns sends an 
HTML/XML command to the respective HAVi-VHN DVD 
DCM 618. HAVi does not know how to interpret XML or 
HTML as HAVi does not use these protocols. The HAVi- 
VHN DVD DCM 618 knows the HAVi protocols as well as 
the VHN protocols. 

[0060] At step S808, the HAVi-VHN DVD DCM 618 
encodes the XML commands from the VHN network into a 
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HAVi messages because the HAVi DVD DCM 621 only 
knows HAVi messaging. Therefore, the VHN protocol has 
been mapped into HAVi messaging that the HAVi DVD 
DCM understands. The DVD player can thus be controlled 
by the HAVi DVD DCM. Consequently, we have a VHN 
application on the VHN network 502 controlling a HAVi 
device. 

HAVi Startup Process 

[0061] Before a HAVi application or device can become 
"HAVi aware," it must go through the HAM startup process. 
In part, this means the application or device registers with 
the HAVi messaging system to obtain a software element 
identification (SEID) which is a globally unique identifica- 
tion in the HAVi network. The SEID is used in the HAVi 
system to allow other HAVI or VHN processes to access the 
application or device. Next the application or device must 
describe itself to the HAVi registry 114. Afterwards the 
application is free to use any HAVI services. This same 
process must be followed for VHN devices or applications 
that want to interface to the HAVi network. This means VHN 
processes wishing to operate in the HAVi network must 
obtain a valid SEID and register with the HAVi registry. 

The VHN Bridge Control Manager (VBCM) 

[0062] The main function of the VBCM 600 is to expose 
HAVi devices to the VHN network and VHN devices to the 
HAVi network 504. When the VBCM first initializes,* it 
registers with the HAVi event manager 120 and request that 
all events related to new/gone device/application. When the 
VBCM receives notice (an event) of new devices or appli- 
cations (an asynchronous event), it queries the HAVi registry 
114 to determine their services. When the VBCM finds a 
HAVi device or application it creates a HAVi- VHN DCM. 
The VBCM indirectly gets an IP address (using VHN's 
DHCP services) and assignes it to the HAVi- VHN DCM 
(getting the IP address is actually done by the HBCM). This 
is so the HAVi- VHN DCM's can send and receive XML 
messages to the VHN network. The HAVi- VHN DCM's 
may contain HTML pages to represent the devices' services. 
If so, the HTML pages can be downloaded from the World 
Wide Web (WWW) or contained in the devices configura- 
tion ROM, or from other resources (e.g., a diskette or 
memory card that ships with device, etc). 

[0063] After a HAVi- VHN DCM is created, the VBCM 
sends an XML message to the HAVi BCM notifying it of a 
new HAVi device or application. The XML message to the 
HAVi BCM is descriptive information about the HAVi 
device or application (model, device type, device manufac- 
turer, etc.) and a unique identifier (SEID). This information 
will be used by the HAVi BCM to register HAVi devices or 
applications in the VHN network. When the HAVi BCM 
successfully configures the HAVi device, it returns an IP 
address to the VBCM. The IP address is used to reference the 
HAVi device in the VHN network. Lastly, the VBCM passes 
the IP address to the HAVI-VHN DCM where it will be used 
to cross reference HAVi messages and XML messages. 
Without this process, HAVi devices or applications would 
not be discovered in a VHN network. 

[0064] Likewise, when the new VHN devices or applica- 
tions are detected by the HAVi BCM, the VBCM 600 will 
receive a message from the HBCM. It is the responsibility 
of the VBCM to register the VHN device or application with 
the HAVI messaging system and registry. In turn, a SEID 
value is generated for the VHN device or application. The 


SEID is used to register the VHN device or application with 
the HAVi registry 114. The registry will be given sufficient 
information about the VHN device or application so that the 
VHN device or application can be discovered in a HAVI 
network. 

[0065] Finally, a HAVi- VHN DCM is created for the VHN 
device or application. This is necessary for VHN devices or 
applications to communicate with HAVi devices and for 
HAVi devices (or application) to communicate with VHN 
device. The HAVi-VHN DCM will translate XML messages 
into HAVi messages and HAVi messages into XML mes- 
sages. Without this process, VHN devices or applications 
would not be discovered in a HAVi network. 

[0066] A final note about the VBCM that needs to be 
pointed out is that it must support all the VHN Internet 
protocols which make it possible to interface into the VHN 
network. This means it will support TCP/IP and Web pro- 
tocols. It will use the IP over IEEE 1394 protocol to send and 
receive XML messages to/from the VHN network. Also, it 
will contain a web server that is able to send HTML pages 
to VHN processes. Likewise, it will contain a modified web 
browser that is able to receive HTML pages and translate 
them into HAVi messages, Java UI (AWT), or DDI objects. 
In some situation, it is possible the HAVi-VHN DCMs may 
contain these and other protocols. This will allow the DCM 
to interface directly with the VHN devices without the aid of 
the HBCM and VBCM. However, in order to keep the 
system light (use less memory) it is desirable to keep the 
VHN protocols in the VBCM and have the HAVI-VHN 
DCM's use the services of the VBCM as needed. 

The HAVi Bridge Control Manager (HBCM) 

[0067] When the HBCM 602 is notified of a new HAVi 
device (or application) by the VHN BCM, it creates an IP 
address for the device using an available DHCP server. A 
map between the IP address and the SEID are maintained by 
the HBCM and VBCM independently of one another. This 
is used to cross-reference a HAVi device when it is being 
referenced in the VHN network as well as a VHN device 
when it is being used in the HAVI network. 

[0068] When the HAVi BCM is notified of a new HAVi 
application or device, it registers the information with the 
HNB & IR 604. This means passing an XML message that 
contains the IP address (and possibly the SEID) and a 
description of the HAVi device or application to the HNB & 
IR. Some of the device or application descriptive informa- 
tion may contain basic information, such as the device 
model, device features and a user-configurable device name. 
Other device manufacture -specific information may be 
included with the device information (i.e., device features, 
device software version, etc.). Without this process, a HAVi 
device or application would not be discovered in a VHN 
network. 

[0069] The HBCM 602 is responsible for notifying the 
HAVi system of VHN processes (new and gone). This is 
accomplished by the HAVi BCM's ability to detect IEEE 
1394 bus resets that helps it detect new VHN devices. Once 
a bus reset is detected, the HAVi BCM queries the HNB & 
IR 604 to discover new/gone VHN devices. In some situa- 
tions VHN devices will not operate on the IEEE 1394 
networks. In this case the HAVi BCM cannot dynamically 
detect VHN devices (or applications), so it is must periodi- 
cally poll the HNB & IR to discover new/gone devices. 
There may be special situations where the HAVi BCM has 
to interface into VHN Backbone Component Interface (BCI) 
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devices to obtain end device information or state conditions. 
These situations would occur when end device or BCI 
devices are unable to report to the HNB & IR. 

[0070] Once the HAVi BCM discovers a new VHN device 
(either by the HNB & IR or a BCI device), it will send a 
XML message to the VHN BCM requesting the VHN 
devices be configured and registered in the HAVi system. 
This will result in the VHN BCM registering the VHN 
device with the HAVi messaging system and returning a 
HAVi SEID. Also, the VHN BCM will register the VHN 
device with the HAVi registry 114 and create a HAM- VHN 
DCM. This will allow HAVi applications and devices to 
interface into the VHN network 502. The HAVi- VHN DCM 
will communicate to the VHN network over XML and RPC. 
When the configuration process is successful, the VHN 
BCM will send the SEID of the VHN device to the HAVi 
BCM signifying the registration process was completed. 
Without this process, a VHN device or application would not 
be discovered or operate in a HAVi network. 

[0071] In one embodiment, as shown in FIG. 9, a VHN 
application can control a HAVi application. The VHN appli- 
cation queries the HNB & IR 604 to discover a HAVi 
application 106, at S900 and S902. The HNB & IR will 
return the IP address (and possible the SEID) of the HAVi 
application. When the VHN application sends an XML RPC 
to the HAVi application, at S904, it will be picked up by the 
HAVi VHN BCM (HAVi- VHN DCM). In turn, the VHN 
XML message will be translated into a HAM message using 
the SEID of the HAVi application, at S906. Furthermore, the 
VHN BCM (via the HAVi- VHN DCM) sends the HAVi 
message to the HAVi application, at S908. 

[0072] When the HAVi application 106 responds back to 
the VHN application, it does so using the VHN SEID 
address that was encoded into the HAVi message. The VHN 
BCM translates (via the HAVi-VHN DCM) the HAVi mes- 
sage into a XML RPC response using the assigned IP 
address of the VHN application. 

[0073] Likewise, referring to FIG. 10, a VHN device 616 
can control a HAVi device. Similar to the example above, the 
VHN device 616 queries the HNB & IR 604 for HAVi 
devices, at S1000. What is returned from the HNB & IR is 
the IP address (and possibly the SIED) of the HAVi device. 
The VHN device is free to send XML messages (using the 
assigned IP address of the HAVi device) to the VHN BCM 
(via the HAVi-VHN DCM), at S1002. The VHN BCM 
recognizes the IP address of the VHN device 616 and 
reformats the XML message into a HAVi message that will 
be sent to the HAVi DCM (via the HAViVHN DCM), at 
S1004. 

[0074] The response from the device's HAVi DCM will 
send a HAVi message to the VHN BCM (HAVi-VHN DCM) 
using its mapped SEID address, at S1006. This will cause 
the VHN BCM to translate the HAVi message into a XML 
message that will be sent to the VHN device, at S1008. The 
SEID and IP address of the devices will be used to cross- 
reference each device (VHN and HAVi). 

[0075] Similarly, a VHN device 616 can control a HAVi 
application 106. The only difference between this case and 
the one above is that the VHN device uses the HAVi 
application IP address which is obtained from the HNB & 
IR. The VHN BCM will translate the IP address of the HAVi 
application into the respective SEID. Everything else is the 
same, and is shown in FIG. 10. 

[0076] Still referring to FIG. 6, in other embodiments 
according to the present invention, the HAVi application 106 


can control a device (e.g., the DTV 616) on the VHN 
network 502. Referring to FIG. 11, as shown in steps SHOO 
and S1102, when the VBCM 600 discovers that there is a 
DTV on the VHN network, it creates the VHN DCM 622 
(HAVi-VHN DCM). The VHN DCM can be considered to 
be a virtual DCM because the DTV physically resides on the 
VHN network and not the HAVi network. 

[0077] Next, at step S1104, the VHN DCM 622 registers 
itself with the registry 114. At step S1106, the HAVi appli- 
cation 106, which is attempting to control a DTV, goes to the 
registry 114 and queries for all DTV's on the network. 
Subsequently, the HAVi application finds the DTV 616 
SEID which enables it to control the DTV's respective 
DCM. The HAVi application does not have information that 
the DTV 616 is a VHN device. 

[0078] At step S1108, the HAVi application 106 can now 
control the DTV 616 (e.g., turn it on or off, set the time, etc.) 
by sending commands to the VHN DCM 622 via HAVi 
messaging. The HAVi application thinks that it is talking to 
a HAVi DCM 124, using the HAVi protocols. Furthermore, 
any of the HAVi software modules that communicate with 
the VHN DCM 622 do so through HAVi messaging. 

[0079] At step S1110, the VHN DCM 622 can now 
communicate with the VBCM 600 via XML and HTML. At 
step, S1112, the VBCM, in turn, communicates with the 
HBCM 602 in XML. The HBCM 602 thus controls the DTV 
616, as shown in step S1114. The result is a HAVi applica- 
tion 106 running on a HAVi network 504 controlling a VHN 
device 616. In some situation, it the VHN DCM (HAVi- 
VHN DCM) can interface directly with the client applica- 
tion. This is done if the VHN DCM contains the IP protocols 
and web protocols. In this case, the VHN DCM using the IP 
over IEEE 1394 protocols to communicate with the VHN 
device. 

[0080] In an alternate embodiment, referring to FIG. 12, 
a HAVi application 106 can control a VHN application. A 
HAVi application queries the HAM registry for VHN appli- 
cations (an SEID of the VHN application is returned), at 
S1200. Once the HAVi application obtains the SEID of the 
VHN application, it is free to send HAVi messages to the 
VHN application. The HAVi-VHN DCM translates the 
HAVi message to XML messages, at S1202 and S1204. The 
SEID of the VHN application is used to retrieve the VHN 
applications IP address. The XML message is transmitted 
using IP/1394. 

[0081] The VHN application uses the IP address of the 
HAVi application when it sends a response. The VHN BCM 
(via the HAVi-VHN DCM) translates the XML message into 
a HAVi message and sends it to the HAVi application, at 
S1206. 

[0082] Moreover, a HAVi device can control a VHN 
device 616, as illustrated in FIG. 13. A HAVi device is able 
to control a VHN device by going to the HAVi registry 114 
and getting the SEID of the VHN device. The HAVi device 
sends a message to the VHN device (via HAVi messaging), 
at S1300. The VHN device's HAM- VHN DCM is able to 
receive the HAVi message and translate it into a XML 
message, at S1302. It maps the SEID address into the VHN 
devices IP address. When the VHN device 616 responds to 
the HAVi device it does so by sending an XML response, at 
S1304. The VHN BCM (via the HAM-VHN DCM) trans- 
lates the XML message into a HAM message and sends it to 
the HAVi DCM, at S1306 and S1308. 

[0083] In another embodiment, as shown in FIG. 14, a 
HAVi device can control a VHN application. A HAVi device 
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can control a VHN device by getting its SEID from the HAVi 
registry 114 and sending it messages, at SI 400. The HAVi 
device's DCM sends HAVi messages to the HAVi- VHN 
DCM which in turn sends XML messages to the VBCM, at 
S1402. The VBCM in turns sends XML messages to the 
VHN application, at S1404. When it comes time for the 
VHN application to respond to the HAVi device, it will send 
XML messages (using the IP address of the HAVi device) 
back to the VBCM. At this point, the message will be parsed 
and passed back to the HAVi- VHN DCM. The HAVi-DCM 
will reformat the VHN message into HAVi messages and 
pass them on to the HAVI DCM. At this point the HAVi 
DCM can send proprietary commands (i.e., AV/C com- 
mands) to the HAVi device. 

[0084] The above description is illustrative and not restric- 
tive. Many variations of the invention will become apparent 
to those of skill in the art upon review of this disclosure. The 
scope of the invention should, therefore, be determined not 
with reference to the above description, but instead should 
be determined with reference to the appended claims along 
with their full scope of equivalents. 

What is claimed is: 

1. A method of facilitating interoperability between two 
networks, the method comprising: 

providing a VHN network having a VHN element; 

providing a HAVi network having a HAVi element; and 

translating messages via a protocol translator coupled 
with the VHN network and the HAVi network; 

wherein the interoperability is facilitated between the 
HAVi element and the VHN element, 

2. The method of claim 1, wherein the protocol translator 
comprises: 

a HAVi bridge control manager; 

a VHN bridge control manager coupled with the HAVi 
bridge control manager; and 

a HAVi- VHN DCM coupled with the VHN bridge control 
manager. 

3. A method of facilitating interoperability between two 
networks, the method comprising: 

providing a VHN network having a VHN element; 

providing a HAVi network having a HAVi element; 

providing a protocol translator coupled with the VHN 
network and the HAVi network; and 

controlling the HAVi element with the VHN element. 

4. The method of claim 3, wherein the protocol translator 
comprises: 

a HAVi bridge control manager; 

a VHN bridge control manager coupled with the HAVi 
bridge control manager; and 

a HAVi- VHN DCM coupled with the VHN bridge control 
manager. 

5. A method of facilitating interoperability between two 
networks, the method comprising: 

providing a VHN network having a VHN element; 


providing a HAVI network having a HAVi element; 

providing a protocol translator coupled with the VHN 
network and the HAVi network; and 

controlling the VHN element with the HAVi element. 

6. The method of claim 5, wherein the protocol translator 
comprises: 

a HAM bridge control manager; 

a VHN bridge control manager coupled with the HAVi 
bridge control manager; and 

a HAVi-VHN DCM coupled with the VHN bridge control 
manager. 

7. The method of claim 5, wherein controlling comprises 
controlling a HAVi device with a VHN device. 

8. The method of claim 5, wherein controlling comprises 
controlling a HAVi device with a VHN application. 

9. The method of claim 5, wherein controlling comprises 
controlling a HAVi application with a VHN device.. 

10. The method of claim 5, wherein controlling comprises 
controlling a HAVi application with a VHN application. 

11. A computer-readable media for facilitating interoper- 
ability between a VHN network having a VHN element and 
a HAVi network having a HAVi element, the computer- 
readable media comprising: 

providing instructions for coupling the VHN network 
with the HAVi network; and 

providing instructions for facilitating interoperability 
between the HAVi element and the VHN element. 

12. The computer-read able media of claim 1, wherein 
providing instructions for facilitating interoperability com- 
prises: 

providing instructions for a HAVi bridge control manager; 

providing instructions for a VHN bridge control manager 
coupled with the HAVi bridge control manager; and 

providing instructions for a HAVi-VHN DCM coupled 
with the VHN bridge control manager. 

13. A system for facilitating interoperability between two 
networks, the system comprising: 

a VHN network having a VHN element; 

a HAVi network having a HAVi element; and 

a protocol translator coupled with the VHN network and 
the HAVi network; 

wherein the protocol translator facilitates interoperability 
between the HAVi element and the VHN element. 

14. The system of claim 13, wherein the protocol trans- 
lator comprises: 

a HAVi bridge control manager; 

a VHN bridge control manager coupled with the HAVi 
bridge control manager; and 

a HAVi-VHN DCM coupled with the VHN bridge control 
manager. 

***** 
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(57) ABSTRACT 

The invention is a system method for providing extended 
functionality for a HAVi compatible device. The HAVi 
compatible device is connectable to a HAVi network. The 
extended functionality is defined by control data stored on a 
remote server external to the HAVi network. The remote 
server is connected to an external network. The external 
network comprises a network external to the HAVi network. 
The HAVi network comprises several other HAVi compat- 
ible devices. The system comprises an external network 
connection device for providing data communications 
between the HAVi network and the remote server. The 
external network connection device is connectable to the 
external network. The external network connection device is 
for receiving the control data from the remote server. The 
system further includes a control module, comprising a 
device control module (DCM) containing a special func- 
tional control module (FCM). The control module is for 
providing the extended functionality for the HAVi compat- 
ible device based on the control data. 
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SYSTEM AND METHOD FOR ENHANCED HAVI 
BASED DEVICE IMPLEMENTATION 

BACKGROUND OF THE INVENTION 
[0001] 1. Field of the Invention 

[0002] The invention is a system and method for enhanced 
HAVi based device implementation. Specifically, the inven- 
tion is a system method for providing extended functionality 
for a HAVi compatible device. 

[0003] 2. Description of the Prior Art and Related Infor- 
mation 

[0004] Recently, a communications standard that allows 
all manner of digital consumer electronics, or home devices, 
to communicate with each other has been established by 
some of the world's leading manufacturers in the field. The 
standard, called the Home Audio Video Interoperability, or 
HAVi, standard allows users to enjoy the convenience of 
easy interoperability of these devices. The types of devices 
supported by HAVi include: tuner, VCR, clock, camera, AV 
disc, display, amplifier, modem, and Web proxy. 

[0005] A specification has been developed for the HAVi 
standard. The HAVi specification was developed mainly for 
home entertainment audio visual (AV) networks, providing 
high bandwidth for transmitting multiple AV streams and 
featuring easy plug-and-play functionality, using an under- 
lying IEEE-1394 digital interface. The HAVi specification 
defines a set of APIs and middleware capable of automati- 
cally detecting devices on the network, coordinating the 
functions of various devices, installing applications and user 
interface software on each device, and ensuring interoper- 
ability among multiple brands of devices. Some of the 
companies involved in developing the specification are: 

[0006] Grundig AG, 

[0007] Hitachi Ltd., 

[0008] Matsushita Electric Industrial Co., 

[0009] Royal Philips Electronics, 

[0010] Sharp Corporation, 

[0011] Sony Corporation, 

[0012] Thomson Multimedia, and 

[0013] Toshiba Corporation. 

[0014] The HAVi specification is currently in its first 
version, last updated Jan. 18, 2000, and can be found in .pdf 
format at www.HAVi.com. 

[0015] HAVi technology allows all devices on a HAVi 
network to be operated from anywhere on the HAVi net- 
work, which is local in nature, using whichever device is 
nearest to the user. HAVi is a digital audio-visual (AV) 
networking initiative that provides a networking software 
specification for seamless interoperability among devices. 
Equally important, the HAVi specification is AV-devi ec- 
centric, so it has been designed to meet the particular 
demands of digital audio and video. It defines an operating- 
system-neutral middleware that manages multi-directional 
AV streams, event schedules, and registries, while providing 
application program interfaces (APIs) for the creation of a 
new generation of software applications. Whatever the 
brand of device, the focus is on the control and content of 


digital AV streams. HAVi software takes advantage of the 
powerful resources of chips built into modem audio and 
video devices to give users the management function of a 
dedicated audio -video networking system. 

[0016] The IEEE 1394 standard (by I.UNK or 
FIREWIRE) has been chosen as the interconnection 
medium. IEEE 1394 has more than enough capacity to 
simultaneously carry multiple digital audio and video 
streams around a local area, for example a house, and 
provides support for digital copy protection. Leading sup- 
pliers of consumer electronics are already committed to 
producing HAVi compatible devices. 

[0017] The HAVi standard gives users instantly coordi- 
nated functionality among usable devices without that user 
becoming a system administrator. Each device added to the 
network automatically installs its own application and inter- 
face software. The complexity and sophistication has been 
built into HAVi compatible devices, with the power of the 
HAVi standard being harnessed to work behind in the 
background so that control is simple for the user. As each 
device is added to a local HAVi network, it's automatically 
registered by the system so that other devices know what it 
is capable of. 

[0018] Devices may possess several functions across 
brands, which is not a problem with the HAVi network 
because HAVi has standardized the application program- 
ming interfaces of the most common AV functions. This 
means that a VCR can search for a device that offers a clock 
with the time-pf-day and automatically set its own timers. 

[0019] HAVi's upgrade able nature means that users are 
able to increase the functionality of devices as updates 
become available. Not even a home PC is required for a 
HAVi network to operate. 

[0020] Functions on a device or device within the HAVi 
networking system may be controlled from another device 
within the system. For example, a search may be performed 
for an available VCR to record a TV program, with com- 
mands being given via a menu selection from another TV 
display. 

[0021] Entertainment products from different manufactur- 
ers may communicate with each other when connected into 
a HAVi network. A variety of VCR's, hi-fis, DVD players, 
minidisc machines, active loudspeakers, set- top boxes may 
all be daisy-chained together to be presented on a TV for a 
user to control from one remote control device. 

[0022] HAVi compliant devices automatically announce 
their presence and capabilities to every other device on the 
HAVi network, greatly simplifying installation and setup. 
The user of the HAVi network simply may add a device on 
a plug-and-play basis. Complicated and difficult installation 
instructions are not required. Nor is any configuration of 
network addresses or device drivers required. 

[0023] Today's i.LINK enabled camcorders and other 
devices are able to be controlled on a HAVi network for 
basic functions. Most HAVi compliant devices come with 
their own dynamic device control modules (DCMs). Updat- 
ing functionality can be done by downloading/uploading 
new capabilities via the Internet. Also, additional or replace- 
ment products can simply be incorporated into the network. 
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[0024] As consumers incrementally build entertainment 
networks from a basic cluster to a home network, exciting 
new applications will emerge to offer additional flexibility, 
control and personalization to home entertainment. The 
HAVi standard makes it easier for companies to build and 
market new application programs by using HAVi's API's or 
programming in Java. Bridges will also be available to home 
control systems, security systems, communication systems 
and PC based applications. 

[0025] The HAVi architecture is intended for implemen- 
tation on consumer electronics (CE) devices and computing 
devices; it provides a set of services which facilitate interop- 
erability and the development of distributed applications on 
home networks. HAVi is intended for, but not restricted to, 
CE devices supporting the IEEE Std 1394-1995 [3] (and 
future extensions) and IEC 61883 [4] interface standards. 
Since a goal of the HAVi architecture is to be future-proof, 
interoperability is more than a common command set. HAVi 
is a software architecture that allows new devices to be 
integrated into the home network and to offer their services 
in an open and seamless manner. The HAVi Architecture 
provides: a set of software elements along with the protocols 
and APIs needed to achieve interoperability; device abstrac- 
tion and device control models; an addressing scheme and 
lookup service for devices and their resources; an open 
execution environment supporting visual presentation and 
control of devices, and providing runtime support for third 
party applications; communication mechanisms for extend- 
ing the environment dynamically through plug-and-play 
capabilities; a versioning mechanism that preserves interop- 
erability as the architecture evolves; and management of 
isochronous data streams. The specification describes the 
constructs HAVi implements to support interoperability. 

[0026] One of the basic operating elements used multiple 
times in HAVi networks comprises a functional control 
module (FCM). A FCM is a HAVi software element that 
provides an interface for controlling a specific functional 
component of a device. Another basic element comprises a 
device control module (DCM). A DCM is a HAVi software 
element that provides an interface for controlling general 
functions of a device. A DCM provides the interface to the 
HAVi network, exposing a set of functionality to the net- 
work. FCMs are functional building blocks that may be 
combined to create the total functionality of a physical or 
virtual multimedia device. Two DCMs could use the same 
set of FCMs to create two different virtual devices. 

[0027] With reference to FIG. 1, the underlying structure 
for a HAVi network 100 comprises interconnected clusters 
60 of HAVi devices 30. Typically, there will be several 
clusters 60 in a network 100, with one per floor or one per 
room. Each cluster 60 will work as a set of interconnected 
devices 30 to provide services to users. Often one device 30a 
will control other devices 30. However, the HAVi architec- 
ture is sufficiently flexible to allow networks 100 with no 
single master control device. 

[0028] The HAVi architecture supports legacy devices 30, 
i.e., devices 30 that are at least not fully compatible with the 
HAVi specification. This is important since the transition to 
networked devices 30 is gradual — with manufacturers not 
suddenly producing only networked devices 30 and con- 
sumers not suddenly replacing their existing devices 30. 


Legacy devices 30 can also be characterized by the degree 
to which they support 1394 and industry standard protocols 
for 1394 such as IEC 61883. 

[0029] Each device 30 has, as a minimum, enough func- 
tionality to allow it to communicate with other devices 30 in 
the system 100, with the exception of legacy devices 30 
which are handled as explained below. During the course of 
interaction, devices 30 may exchange control information 
and data in a peer-to-peer fashion. This ensures that, at the 
communication level, no one device 30 is required to act as 
a master or controller for the system 100. However, it also 
allows a logical master or controller 30a to impose a control 
structure on the basic peer-to-peer communication model. 
The HAVi control model makes a distinction between con- 
trollers 30a and controlled devices 30. A controller 30a is a 
device that acts as a host for a controlled device 30. A 
controlled device 30 and its controller 30a may reside on the 
same physical device 30 or on separate physical devices 30a. 
In terms of the HAVi control model, a controller 30a hosts 
a device control module (DCM) for the controlled device 30. 
The control interface for a device 30 is exposed via an API 
of the DCM. This API is the only access point for applica- 
tions to control the device 30. For instance, an intelligent 
television in the family room might be the controller 30a for 
a number of interconnected devices 30, A controlled device 
30a could contain Java bytecode that constructs a user 
interface for the device 30 and allows external control of the 
device 30. When the devices 30 are first connected, the 
controller 30a obtains the user interface and control code for 
the device 30 comprising the DCM for the device. An icon 
representing the device 30 may then appear on the television 
screen, and manipulating the icon may cause elements of the 
DCM to actuate the represented device or devices in pre- 
scribed ways. The network 100 allows a single device 30, or 
a group of devices 30 communicating amongst themselves, 
to deliver a service to a user. When it is necessary for a 
device 30 to interact with a user, a GUI for the device may 
be presented on a device 30 with display capabilities (pos- 
sibly the device in question or possibly a different device). 

[0030] With reference to FIG. 2., DCMs are a central 
concept to the HAVi architecture and the source of flexibility 
in accommodating new devices 30 and features. A chart 200 
in FIG. 2 illustrates how DCMs can be distinguished in 
several ways. The first DCM characteristic is how the DCM 
is obtained by the controller. For example, the DCM may be 
embedded. An embedded DCM is a DCM that is part of the 
resident software on a controller 30a. A DCM may also be 
uploaded. An embedded DCM is one that is obtained from 
some source external to the controller 30a and is dynami- 
cally added to the software on the controller 30a. 

[0031] The second characteristic is whether a DCM is 
controller 30a dependent or controller 30a independent. For 
example, a DCM may be native. A native DCM is one that 
is implemented for a specific platform. It may include 
machine code for a specific processor or access platform 
specific APIs for a device. A DCM may comprise a bytecode 
DCM. A bytecode DCM is one that is implemented in Java 
bytecode. 

[0032] Finally, DCMs can be distinguished by their func- 
tionality, or, conversely, their range of use. For example, a 
DCM may comprise a standard DCM. A standard DCM is 
one that provides standard HAVi APIs. Such a standard 
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DCM provides basic functionality but is able to control a 
wide range of devices. A DCM may comprise a proprietary 
DCM. A proprietary DCM is a DCM that provides vendor- 
specific APIs in addition to the standard HAVi APIs. Such a 
proprietary DCM would offer additional features and capa- 
bilities over a standard DCM but could control a narrower 
range of devices, perhaps only a specific device 30 or model 
of a device 30. 

[0033] A DCM, is a software abstraction of a device 30 
providing device 30 specific functionality to the HAVi 
network 100. HAVi applications will not communicate with 
a device 30 directly but through the DCM of the device 30 
or one of its FCMs. A DCM is a HAVi object in the sense that 
it is registered in a general registry with other HAVi objects, 
and can communicate with other HAVi objects via a general 
HAVi Messaging System. DCMs and FCMs are registered 
with their type and a HAVi unique identifier (HUID). The 
HUID allows applications to find the DCM or FCM after 
partial system unavailability, as when the device 30 repre- 
sented by the DCM is momentarily removed from the 
network 100. A DCM provides a set of basic methods for 
device 30 control and observation. The DCM can be used by 
HAVi devices 30 as well as any application. 

[0034] A distinction is made between devices 30 which are 
each described to the network 100 by their DCM, and 
functional components of a device 30 which are described to 
the network 100 by FCMs within the DCM for the device 30. 
A good example of this distinction can be found in a normal 
TV set. Although the TV set is generally one physical box, 
it contains several distinct controllable entities, e.g. the 
tuner, display, audio amplifier, etc. The controllable entities 
within a device are called functional components. The TV is 
the device 30 defined to the network with its DCM, and the 
functional components are defined by FCMs within the 
DCM. 

SUMMARY OF THE INVENTION 

[0035] The invention is a system and method for providing 
extended functionality for a HAVi compatible device. The 
HAVi compatible device is connect able to a HAVI network. 
The extended functionality is defined by control data stored 
on a remote server external to the HAVi network. The remote 
server is connected to an external network. The external 
network comprises a network external to the HAVi network. 
The HAVi network comprises several other HAVi compat- 
ible devices. 

[0036] The system comprises an external network connec- 
tion device for providing data communications between the 
HAVi network and the remote server. The external network 
connection device is connectable to the external network. 
The external network connection device is for receiving the 
control data from the remote server. 

[0037] The system further includes a control module, 
comprising a device control module (DCM) containing a 
special functional control module (FCM). The control mod- 
ule is for providing the extended functionality for the HAVi 
compatible device based on the control data. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0038] FIG. 1 is a block diagram illustrating the under- 
lying structure for a HAVi network according to the prior art; 


[0039] FIG. 2 is a chart illustrating how prior art DCMs 
can be categorized; 

[0040] FIG. 3 is a block diagram illustrating a system for 
providing extended functionality for a HAVi compatible 
device according to the present invention; 

[0041] FIG. 4 is a flow diagram illustrating the steps 
performed in a method performed by the system of FIG. 3; 
and 

[0042] FIG. 5 a block and data flow diagram illustrating 
the components and a process for retrieving control data 
from a remote server of the system of FIG. 3. 

DETAILED DESCRIPTION OF THE 
PREFERRED EMBODIMENTS 

[0043] With reference to FIG. 3, a system for providing 
extended functionality for a HAVi compatible device 306 is 
shown. The HAVi compatible device 30b is connectable to 
a HAVi network 100. The extended functionality is defined 
by control data 422 stored on a remote server 420 external 
to the HAVi network 100. The remote server 420 is con- 
nected to an external network 350. The external network 350 
comprises a network external to the HAVi network 100. The 
HAVi network 350 comprises several other HAVi compat- 
ible devices 30. 

[0044] The system comprises an external network connec- 
tion device 120 for providing data communications between 
the HAVi network 100 and the remote server 420. The 
external network connection device 120 is connectable to 
the external network 350. The external network connection 
device 120 is for receiving the control data 422 from the 
remote server 420. 

[0045] The system further includes a control module, 
shown as device control module (DCM) 32b containing a 
special functional control module (FCM) 34b in FIG. 3. The 
control module 32£>-34/> is for providing the extended func- 
tionality for the HAVi compatible device 30b based on the 
control data 422. In FIG. 3, the DCM 326 is shown 
containing several FCMs 34 and the special functional 
control module 34b. The DCM 32b is for presenting the 
functionality of the HAVi compatible device 30b to the 
HAVi network 100. 

[0046] The device control module 32b may be included on 
a master control device 30a comprising a processor con- 
nected to the HAVi network 100. The processor 30 has a 
memory module 38 for storing the DCM 32b and functional 
control module 34b. DCMs 32 for the other HAVi compat- 
ible devices 30 are present on the master control device 30, 
with each of the DCMs containing FCMs 34 for those 
devices. 

[0047] The processor 30a may further comprise the exter- 
nal network connection device 120 as opposed to the exter- 
nal network connection device 120 being directly connected 
to the network 120. The external network connection device 
120 may comprise a modem, cable modem, ISDN device, or 
DSL connector. 

[0048] The processor 30a is for presenting the device 
control module 32b to a user of the HAVi network 100 for 
providing the user with the capability of controlling the 
HAVi compatible device 32a with the extended functional- 
ity. The device control module 32b is presented with the its 
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functional control modules 34-346 in the display presented 
by the DCM 346 described in the HAVi specification. There 
is a FCM 346 for the legacy device 306 and an FCM 346 for 
a virtual device representing the functionality of a set of 
control data 422 stored on a remote server 420. A single 
DCM 326 exposes the combined functionality of the legacy 
device 306 and the control data 422 so that it has the same 
DCM 326 interface as a more intelligent, or contemporary, 
non- legacy device, and therefore causes the legacy device 
306 to appear to the user as if it were a non- legacy device 
306. 

[0049] The HAVi compatible device 306 may comprise a 
legacy device wherein the extended functionality is for 
causing the HAM compatible device 306 to function as a 
contemporary device with respect to a user of the HAVi 
network 100. For example, the HAVi compatible device 306 
may comprise a compact disk player not having built in 
ability for presenting artist and song information for a 
compact disk inserted into the compact disk player. The 
control data 422 may thus be for presenting artist and song 
information for the compact disk to the user. The control 
data 422 would thus comprise artist and song information 
matched to one or more identification codes read from the 
compact disk such that the artist and song information may 
be presented to the user for selection. 

[0050] Another embodiment of the system comprises a 
first usable device 306 comprising one of a plurality usable 
devices 30 capable of being connected to a local network 
100. Each usable device 30, 30a, 306 is capable of receiving 
commands from a user of the local network 100. 

[0051] The external network connection device 120 is for 
providing data communications between the local network 
100 and a remote server 420 connected to the external 
network 350. The external network connection device 120 is 
thus connectable to the external network 350. The network 
connection device 120 is for receiving control data 422 from 
the remote server 420. The control data 422 defines extended 
functionality for a first 306 of the one or more of the plurality 
of usable devices 30-306. One or more control modules 
326-346 is for providing the extended functionality for the 
one or more usable devices 306 based on the control data 
422. 

[0052] One usable device 30a of the plurality of usable 
devices comprises a processor having a device control 
module 326. The device control module 326 comprises a 
first functional control module 346 for presenting the 
extended functionality through presentation of the device 
control module 326 to a user of the processor 30a for 
controlling the first usable device 306, thereby allowing the 
user to use the extended functionality. 

[0053] The extended functionality comprises a plurality of 
extended functions for controlling the first usable device 
306. The device control module 326 comprises a plurality of 
functional control modules 34-346. Each functional control 
module 34-346 comprises a subset of the plurality of 
extended functions. 

[0054] The plurality of usable devices 30, 30a, 306 may 
comprise two or more processors 30a. The device control 
module 326 may present a selected one of the functional 
control modules 34-346 to each of the two or more proces- 
sors 30a, thereby allowing a user of each of the two or more 


processors 30a to control the first device 306 based on the 
respective subset of extended functions of the respective 
functional control module 34-346 presented to the respective 
processor 30a. 

[0055] One or more device control modules 32c may be 
constructed from various functional control modules 34 
from other device control modules 32. This is useful for 
usable devices 30 that may have functionality defined by 
functional control modules from two or more different 
device control modules 32 that may present the device 
control module 32c to the HAVi network 100 with those 
functional control modules 34. 

[0056] With reference to FIG. 4 a flow diagram illustrat- 
ing the steps performed in a method for providing extended 
functionality for a HAVi compatible device 306 is shown. 
The first step comprises providing data communications 
between the HAVi network 100 and the remote server 420, 
step 470. The next step is that the control data 422 is 
received from the remote server 420, step 472. The extended 
functionality for the HAVi compatible device 306 is then 
provided to a user of the HAVi network 100 based on the 
control data 422, step 474. The step of providing the 
extended functionality to the user comprises providing the 
user with the capability of controlling the HAVi compatible 
device 306 with the extended functionality by presenting the 
device control module 326 to the user of the HAVi network 
100. 

[0057] With reference to FIG. 5, a diagram illustrating the 
components and a process for retrieving the control data 422 
from the server 420 is shown. The server 420 contains the 
control data 422. The control data 422 may be formatted into 
a database containing control data records 424. Each control 
data record 424 includes, for example, control data for a 
compact disk title. Each control data record 424 may include 
an identification code 426 provided by a publisher of the 
publisher of a respective compact disk. 

[0058] The HAVi device 306 may be loaded with a com- 
pact disk 502 having an identification code 504. When the 
compact disk 502 is loaded into the HAVi device 306., the 
identification code 504 is provided to the DCM 326 for the 
HAVi device 306, step 550. The identification code 504 read 
from the compact disk 502 is forwarded to the remote server 
420, step 552. The identification code for the compact disk 
504 is matched with an identification code 426 in a control 
data record 4246. Title and artist information from the 
control data record 424 is transmitted back to the FCM 346 
of the DCM 32 that provides the extended functionality for 
the HAVi device 306, step 554. The artist and title informa- 
tion may now be presented for selection by a user on one of 
the HAVi devices 30, 30a or 306 in the HAVi network 300. 

[0059] The above example illustrates operation of the 
system wherein the HAVi device 306 is a compact disk 
player. However, those skilled in the art would recognize 
other combinations of HAVi devices 30 and types of control 
data 422. For example, the HAVi device 306 may comprise 
a television set that does not have digital menu presentation 
firmware built in. In this case, the control data record 424 
that is matched may include digital channel grid information 
for presenting local television program information. The 
DCM 326 for the television 306 may convey a zip code or 
a geographic location code for identifying the local televi- 
sion viewing area for the user. The geographic location code 
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may comprise the identification code 504 that is matched 
with the control data record identification code 426 in the 
control data record 424. Local television program informa- 
tion may thus be downloaded from the server 420 to the 
FCM 34b for presentation on the viewing screen of the 
television 30b through the DCM 32b. 

[0060] While the particular method and apparatus shown 
and described herein in detail is fully capable of attaining the 
objects of this invention, it is understood that the description 
and drawings represent the presently preferred embodiment 
of the invention and are, as such, a representation of the 
subject matter which is broadly contemplated by the present 
invention. It is further understood that the scope of the 
present invention fully encompasses other embodiments that 
may become obvious to those skilled in the art, and that the 
scope of the present invention is accordingly limited by 
nothing other than the appended claims. 

What is claim is: 

1. A system for providing extended functionality for a 
HAVi compatible device, the HAVi compatible device being 
connectable to a HAVi network, the extended functionality 
defined by control data stored on a remote server external to 
the HAVi network, the remote server being connected to an 
external network, the external network comprising a net- 
work external to the HAVI network, comprising: 

an external network connection device for providing data 
communications between the HAVi network and the 
remote server; 

the external network connection device connectable to the 
external network; 

the external network connection device for receiving the 
control data; and 

a control module for providing the extended functionality 
for the HAVi compatible device based on the control 
data. 

2. The system of claim 1 wherein the control module 
comprises a functional control module. 

3. The system of claim 2 wherein the control module 
further comprises a device control module. 

4. The system of claim 3 wherein the device control 
module comprises a processor connected to the HAVi net- 
work, the processor having a memory module for storing the 
device control module; the processor further comprising the 
external network connection device. 

5. The system of claim 4 wherein the processor is for 
presenting the device control module to a user of the HAVi 
network for providing the user with the capability of con- 
trolling the HAVi compatible device with the extended 
functionality. 

6. The system of claim 1 wherein the HAVi compatible 
device comprises a legacy device wherein the extended 
functionality is for causing the HAVi compatible device to 
function as a contemporary device with respect to a user of 
the HAVi network. 

7. The system of claim 6 wherein the HAVi compatible 
device comprises a compact disk player not having built in 
ability for presenting artist and song information for a 
compact disk inserted into the compact disk player, and 
wherein the control data is for presenting artist and song 
information for the compact disk to the user. 


8. The system of claim 7 wherein the control data com- 
prises artist and song information matched to one or more 
identification codes read from the compact disk such that the 
artist and song information may be presented to the user for 
selection. 

9. A system comprising a first usable device comprising 
one of a plurality usable devices capable of being connected 
to a local network, each usable device being capable of 
receiving commands from a user of the local network: 

an external network connection device for providing data 
communications between the local network and a 
remote server connected to an external network, the 
external network connection device connectable to the 
external network, the external network connection 
device for receiving control data from the remote 
server, the control data defining extended functionality 
for a first of the one or more of the plurality cf usable 
devices; and 

a control module for providing the extended functionality 
for the first usable device based on the control data. 

10. The system of claim 9 wherein a second of the 
plurality of usable devices comprises a processor having a 
device control module. 

11. The system of claim 10 wherein the device control 
module comprises a first functional control module, the 
device control module for presenting the extended function- 
ality to a user of the processor for controlling the first usable 
device, thereby allowing the user to use the extended func- 
tionality. 

12. The system of claim 10 wherein the extended func- 
tionality comprises a plurality of extended functions for 
controlling the first usable device; two or more device 
control modules each comprising a plurality of functional 
control modules, each functional control module comprising 
a subset of the plurality of extended functions, the plurality 
of usable devices comprising two or more processors, each 
of the device control modules for presenting selectively to 
one of the two or more processors, thereby allowing a user 
of each of the two or more processors to control the first 
device based on the respective subset of extended functions 
of the respective functional control modules of the device 
control module presented to the respective processor. 

13. A method for providing extended functionality for a 
HAVi compatible device, the HAVi compatible device being 
connectable to a HAVi network, the extended functionality 
defined by control data stored on a remote server external to 
the HAVi network, the remote server being connected to an 
external network, the external network comprising a net- 
work external to the HAVi network, the method comprising 
the steps of: 

providing data communications between the HAVi net- 
work and the remote server; 

receiving the control data from the remote server; and 

providing the extended functionality for the HAVi com- 
patible device based on the control data. 

14. The method of claim 13 comprising providing the user 
with the capability of controlling the HAVi compatible 
device with the extended functionality. 

15. The method of claim 13 wherein the HAVi compatible 
device comprises a legacy device wherein the extended 
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functionality is for causing the HAVi compatible device to 
function as a contemporary device with respect to a user of 
the HAVi network. 

16. The method of claim 15 wherein the HAVi compatible 
device comprises a compact disk player not having built in 
ability for presenting artist and song information for a 
compact disk inserted into the compact disk player, and 
wherein the control data is for presenting artist and song 
information for the compact disk to the user. 


17. The method of claim 16 comprising reading one or 
more identification codes from the compact disk and match- 
ing the one or more identification codes with the control data 
to present the artist and song information such that the artist 
and song information may be presented to the user for 
selection based on the identification code. 

* * * * * 
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